We could lock this order into "drag to column" interactions only once those are built (i.e., not support "drag to position" -- basically, when you drop a card, we fling it into the correct position, even if that position is at the bottom of the column far off the screen). This will be somewhat confusing but maybe the least-bad of the options.

This now exists for priorities. I'd like to get at least one more grouping (likely: assignee) built before calling this resolved since "Priority" has some magic interaction with "subpriority". I'm moving toward getting rid of "subpriority" in D20263, but I'm not yet completely sure that it'll stick.

Drag-and-drop between columns on a priority-sorted board no longer changes priority. See T13074 for continuing adjacent work.

Some adjacent work in T13074 may build on this, and we might do "drag + shift" at some point, but this is substantially resolved.

In the future, when a board can be ordered/grouped by author or assignee (or maybe custom fields), what should dragging a card within a column do?

Technical stuff:

Currently, if a card requires MFA to edit, we're unable to prompt the user. We likely should be able to do a prompt inline. This should also probably have a warning icon on the card itself.

I'm going to start here, and implement this proposed rule, which I think is the simpler and more intuitive of the proposals:

In T8135#195972, @johnny-bit wrote:

Maaaybe Iam misinterpreting but if enabling sort by priority why not show in workboards something like [...]

Another possibility for assigning to members not already on the board would be to add an "Another User…" category, perhaps only once you start dragging, and if you drop on it, you have to select/type a user in a modal dialog to complete the 'drop' operation (or cancel it). This might work better than guessing; every column would have "Unassigned", headings for users with tasks actualy in that column, and "Another User…". On the other hand, for us, guessing is likely to result in a lot of wasted space, because the users we assign to in different columns are very different. The feature would quite probably be useful to us, though, as moving columns concurrently with reassignment is an extremely common task for us.

In T8135#195971, @chad wrote:

@olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

Maaaybe Iam misinterpreting but if enabling sort by priority why not show in workboards something like

@olivier-squid is the main issue people don't know it's going to happen, or that we just get it wrong. Will the headers help or are you expecting this to just not happen at all when you drag (ie, no sort changes happen at all).

I mean, it's probably not worse-worse, and but it feels like trading one kind of confusion for possibly-moderately-less-confusion more than putting a reasonable stopgap behavior in place until we can fix it properly.

Oh. To me, that's sort of worse? You end up with "Sort by priority" and your tasks aren't actually sorted by priority if you've moved them between columns, and jump around if you reload, and other users won't see the same ordering if they're trying to follow along in a presentation or whatever.

I think I'm doing a bad job at saying that though.

I'm suggesting removing it until T10333

Sorry, I think I'm still not understanding. When the column is grouped by priority, I still expect the auto-reprioritize behavior to work more or less as it does today: if you drag a task into the "High" group, it will change to "High" priority. I don't think we can avoid that without greater confusion.

I assume "Group by" would have dragging support, so by assignee, I could easily re-assign tasks. With that in mind "Group by" and priority, you could drag and drop by priority, thus allowing us to remove the "automatic" feature we have today in the current priority sort.

@chad Oh, maybe I'm misunderstanding. What are you proposing, specifically?

I think my question is, maybe noone wants this feature.

I think of T10333 and what remains here as mostly the same task -- I don't plan to make sorting and grouping separate (offhand, I can't come up with much of a good reason to group + sort, and if we did support that it would recreate a small version of this problem within groups).

@chad, T10333 may address this, but looks very complex for a very simple issue.
Believe me, everyone using phab in my company complained about the priorities being automatically changed.
Sorting by Priority is a very common/natural way of using boards.
You should at least propose a setting in Phab to disable this feature - this would make everyone happy.

Natural sort is the default. If you switch sorting by priority, then this feature comes up. The only thing left on this task (since natural sort is now the default) is implementing a UI around the drag and drop for clarity. T10333 is that task.

It isn't the default.

Hi @chad , I'm talking about this issue : "drag & drop on a workboard sorted by priority behavior is surprising" which I understand to be the scenario where you move a task form a column to another in a board and if you're sorting by priority the task might have its priority changed depending on where on the column you drag it.
This behaviour in completely insane - I understand that someone may have thought of this being a shorthand - but it's a very bad idea to implement this behaviour by default.
Apart from this, Phab is awesome.

I consider this mostly resolved. Can you open a ticket with complete steps to reproduce per Contributing Bug Reports if you are still seeing issues. I honestly have no idea what "nightmare" or "here" means.

Could you please raise the priority of this issue? It's a daily nightmare for all folks here.

• I'd currently consider this a user-expectation issue, but we're doing ourselves zero favors by not providing any kinds of hints about what expectation you should have. We should fix this first. I've realigned this task to discuss making the expectations/behavior more clear.
  • I believe the "edit permission is necessary" part of this rule is hard to reasonably get away from in light of column triggers (T5474). Not impossible, but hard.
  • The "edit permission is sufficient" part of this rule is easy to get away from, but we don't actually have use cases for requiring an additional project permission component right now (T6502).

The strict answer to this is "click the Edit button to go to the full edit UI". We can't make all possible reassign operations accomplishable by dragging, so this has to be the safety net for the cases where we can't guess who your likely assignees are. But I suspect we can do pretty well most of the time with some set of those rules, and make the cost of guessing wrong low.

If so, how do I assign something to a member (or whomever) who doesn't yet/right now have a shown task?

That is, this is a valid column:

There's some argument for showing more headers than the actual assignees, so you can assign a task to someone with no tasks currently assigned.

It's just Group By Assignee, so of all the tasks on the board, who is doing what, how much work is it, and what is unassigned.

I like this idea. For the "assignee" options, what would the ones shown be?

We could do the whole-column thing, but I worry it would be confusing / not useful.

Admittedly I didn't fully grok your description, just how I pictured it in my head. What I was thinking was grouping a whole column by say a Person (like we did in Dashboards) you can see their points and drag work between them. If we go with grouped headers inside the column... how would that work for people? You'd just have their points for that column in the header?

Oh. I assumed the entire column was a group.

Here's the feature I'm thinking about:

Yeah I'm not sure how they'd appear twice in the same column, just multiple times on the board ("Easy", "Bug Report")

Oh, wait. Maybe we're talking about different things. Let me draw a picture.

Absolutely not ever implementing that, because it allows a card to appear multiple times in the same column and requires me to rewrite all the workboard code again.

Another possible Group By is by project. So going into Differential and grouping by projects should allow me to see all Bug Reports in their own column.