Mabe the request here is that workboard filters set by users should be sticky, whatever they are. Now they need to be set manually every time you land in a board. See another request in these lines at https://phabricator.wikimedia.org/T76913

See also T6683#86272 -- maybe we should morph this into the "presentation mode" super task?

We don't currently plan to support this, but see T5474 for binding workflows to columns more tightly. We may also implement some sort of "done" column, but likely only if T5474 is insufficient on its own.

Specific subsets of cards. E.g. "move all resolved bugs from column "in progress" to column "done"", or "move these 30 bugs that I've selected from column "backlog" to column "in progress"".

It is intentional that you can only reorder and rename it. Some discussion in T6469

So I think this task should be merged in {T4408}

I have been hit by that as well https://phabricator.wikimedia.org/T75716 In short you cannot delete columns but can only hide them see: D9719. Quoting myself:

@ahoffer2, are your use cases covered by "Move all cards in this column to <another column>", or are they more around moving a specific set of cards (but not all of the cards in a column)?

We would like to request this feature as well, it comes up a lot for us

Closed by commit rPc2f0955e9bd2.

In T4900#82982, @qgil wrote:

Do you venture to make a very rough estimation of the work required to implement this feature? Not necessarily by you, that is a different discussion. If we have a strong case and a theoretical plan, we might be able to help implementing it.

@chad, I think you mentioned this -- feel free to steal it if that seems manageable.

Oh, it's more complicated than that -- $object is the task. To figure out the project, do something like:

I wanted to do this in an ultra-general way that would let users disable it by disabling a custom field, but let's do it the realistic way first and I can generalize it into space later:

@epriestley, ok, that works too. You see, you wouldn't hire me as an engineer. :P

In T6502#83050, @chad wrote:

I feel like 'Can Edit Workboard' should grant 'Can Edit Task'.

In T6502#83049, @qgil wrote:

Is this summary correct, then?

When a user tries to move a card in a workboard...

I feel like 'Can Edit Workboard' should grant 'Can Edit Task'.

Is this summary correct, then?

Yep, exactly.

Oh Can Edit Workboard is a Project Policy, not a Maniphest Policy, correct?

(I think that would be a reasonable default, although the actual default-default would have to be "members of current project", which doesn't exist until T5681.)

Yeah, just set "Can Edit Workboard" to "Members of Project 'Security'".

Would there be any future path to ... say only Security can edit Security Workboard...

That said, I do think a separate permission is probably reasonable, but you'd need both ("Can Edit Workboard", "Can Edit Task") to drag.

Thinking on it a little more, I like it conceptually but think we can't get away with it:

Yeah, conceptually priority is also task management/planning like workboards and everything else is task definition.

Specifically, you'd lean toward requiring the separate policy only (you don't need to be able to edit the task, as long as you can edit the board)?

I'd lean towards separate policy. Editing a task is primarily changing the definition of a task, where Workboards are the planning/implementation of a Task.

It's supposed to be the "Can Edit" for the task, although that doesn't look like it's currently enforced (the UI sort of respects it, but not really).

This request keeps coming and coming. Most if not all our teams have remote members and their sprint meetings are organized via online hangouts. While they discuss tasks, owners, priorities, blockers... different people move their cards, and everybody follows the moves in their screens.

Yeah, I think T5523 makes this much less painful:

After reload the '(Backlog)' part shows up.

It's not a planned every day part of a workflow. More like:

"Move all tasks in this column" sounds generally pretty awesome to me.

T5523 covers moving stuff on Workboards in bulk.

So I think making it more clear which one is default is good. However, even not-confused users find it annoying and error prone to have to drag dozens of tasks around to change the default via the rename dance.

Closed by commit rP7a6684b73bfe.

I think we can stem most of this with better design, and see if other use cases for manually setting the default appear down the road.

The default board is the one with the icon, perhaps it should be made even more clear. My concern is if it was more clear which column the default was, would we need to build this feature at all? We try to make sure we're resolving the core issue.

Ideally something like: Workboard → Edit a column → Is default: boolean

What are you suggesting, a button or something that says this is the default board now or just the very concept of a default? What specifically are people confused by?

I see that @chad discussed a solution very similar to what I mention above in T4673#53132. Hope this is something that is feasible to implement.

We've started using Workboards more extensively in projects now, and this is definitely an important use case for us.

We'll fix this eventually, but this isn't a priority and may require a more general approach (see also T665). As a workaround, you should be able to reload the page.

Thanks @chad !

Replacing Project Pages with a customizable Dashboard seems like it'd solve most of these cases, at least.

Generally speaking, Phriction isn't our Product Management app. Workboards are, and maybe Dashboards to some other extent. We'd rather improve these to cover use cases that fit maybe how your company works, rather than pursue edge case use in Remarkup or Phriction. We have a lot planned around Workboards, and it is one of products we really want to have cover a lot of cases. Please take a look at Workboards and see what already is planned, and if something you'd think would benefit many Phabricator users is missing, feel free to file.

Yup, here's how you replicate

Nope, Yup: this is what I mean

It sort of feels like the "grey" state is when the workboard is waiting on the server to update the new list position. It could be that it's timing out or otherwise failing on my computer right now. I haven't yet been able to replicate it with developer console open—I don't yet see anything weird.

I just replicated it again. Typically what occurs is after a few drags upon drop a Task box freezes in "selected" state (e.g. darker grey) and then no more boxes can be dragged.

I am not able to reproduce this issue. Tested Safari, Firefox, Chrome all on Yosemite. Is there anything obvious in the developer console?

Version: Safari Version 8.0 (10600.1.25), OS X 10.10 Yosemite
Phabricator: 1120c465e480f503686ab503e2cf1e1f1b6cf16d

We do not plan to implement that. See T6409 for some discussion.

It would be good if this could happen the other way around, making task status influence which column the task is in

We don't plan to implement this. One issue is that it would conflict with T5474, which is a more general and powerful mechanism.

Closed by commit rPe43305278ac9.