See T5474. I'd expect this to get resolved as having this automagical prioritization trigger be made more explicit alongside the rest of T5474. I should go on the record that I love this behavior and wouldn't want to simply remove it. :D

It's also results in inconsistencies with the natural sort behavior: with natural sort dragging to the bottom of a column makes that task the least important thing in that column, while with priority sort it makes it tied with whatever is currently at the bottom (if everything is Normal you can't drag to Low).

I think that should be fixed here too, though its unclear to me how to go from currently-tied-at-Normal, to letting you drag to Low and even lower priorities which may exist . Kind of reminds me of T8120.

In T8135#112918, @btrahan wrote:

See T5474. I'd expect this to get resolved as having this automagical prioritization trigger be made more explicit alongside the rest of T5474. I should go on the record that I love this behavior and wouldn't want to simply remove it. :D

I get the workflow where this could be nice for re-ordering within a column, but how often do you move between columns and change priority at the same time on this install?

I do this all the time. For example, new conpherence bugs are filed and are in the "backlog" column. I then drag them to "v2" (if I think they are pressing and they tend to be bugs being reported) and change priority at the same time. I don't change priority as often if moving from v2 to v3 but its also not a rare action and its easy for me to just drag it to the right spot to not change priority. <3 <3 <3 this feature :D

That said, I don't triage the whole install via a project workboard; just ones I am actively working on like conpherence.

Huh weird, our desires for what this feature would do are just complete opposites.

I tried carefully dragging a Low priority task from column A to the bottom of column B where the lowest priority so far was Normal. This still changed the priority from Low to Normal.

I think the likely way forward is:

• Distinguish between "drag to column" and "drag to position". This probably means that dragging a card near a column moves it to "the same place" in that new column, and dragging a card into a column moves it to a specific position, but maybe this actually needs to be more complicated and/or have preferences ("never drag a card to a specific column position in the priority view unless I hold shift"). In the "natural" ordering, these operations would be identical.
• Add priority-level dividers to columns sorted by priority so that all priorities are selectable, per this mock: https://secure.phabricator.com/M10/10/

This represents a fair amount of work and only affects the priority ordering, which I believe is only lightly used after the introduction of the "natural" ordering, so it's hard to prioritize work here.

I tried carefully dragging a Low priority task from column A to the bottom of column B where the lowest priority so far was Normal. This still changed the priority from Low to Normal.

I believe this worked at one point, so I may have broken it (likely in connection with D12121) or there may be a later-introduced interaction complexity, like a lower-priority task in the column which wasn't visible in your current filter.

Broadly the way forward make sense to me.

and only affects the priority ordering, which I believe is only lightly used after the introduction of the "natural" ordering, so it's hard to prioritize work here.

I'm not sure what you mean by 'lightly used'. This install certainly doesn't leave everything in 'Needs Triage' and then just rely on natural sort ordering on workboards and @btrahan is a fan.

I tried to repro on this install with #cburroughs_personal_test_project so there are not a million spooky closed tickets. The starting position was a wishlist task in column A, and a Normal one in column B. I then dragged from A to the bottom of B.

• With natural sorting this errors:
  
• With priority sorting it changes the priority: https://secure.phabricator.com/T8113#113901

I'm not sure what you mean by 'lightly used'.

Oh, I just mean "order by priority, on workboards", not priority as a whole.

M10 Workphlow

210

I had originally designed dividers into the columns for clarity. We removed them since typically they're clutter, but I wonder if we could instead just activate them when hovering a card over a column.

In T8135#113908, @chad wrote:

I had originally designed dividers into the columns for clarity. We removed them since typically they're clutter, but I wonder if we could instead just activate them when hovering a card over a column.

I was thinking of just adding them unconditionally --but only when ordering by priority -- per above:

Add priority-level dividers to columns sorted by priority so that all priorities are selectable, per this mock: https://secure.phabricator.com/M10/10/

Do you think they're too cluttery to show by default even in the priority ordering?

haha, I didnt see your comment. I do think they may eat up space on active, large boards, but maybe it's not a problem. I thought you were the one to originally not want to build the indicators. Visually, we can reduce the UI a bit, no problem.

Yeah, I think we can probably slim them down a hair and make them work. Installs that define 200 priorities will get questionable results, but I don't feel too bad about that.

This was causing a lot of headache to our team, so we simply switched off change of the priority (by @erik.fercak), may be this would help someone too, until the problem is resolved:

diff --git a/src/applications/project/controller/PhabricatorProjectMoveController.php b/src/applications/project/controller/PhabricatorProjectMoveController.php
index a22050e..023b1c0 100644
--- a/src/applications/project/controller/PhabricatorProjectMoveController.php
+++ b/src/applications/project/controller/PhabricatorProjectMoveController.php
@@ -130,7 +130,7 @@ final class PhabricatorProjectMoveController
         }
       }

-      if ($pri !== null) {
+      if (false && $pri !== null) {
         $xactions[] = id(new ManiphestTransaction())
           ->setTransactionType(ManiphestTransaction::TYPE_PRIORITY)
           ->setNewValue($pri);

Every... day...

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

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.

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.

It isn't the default.

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.

I do wonder @epriestley if we can out-right remove this feature from "sorting" and push it into T10333 under "grouping".

@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.

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).

We could replace the words "Sort by" with "Group by" in the menu after T10333 if that's clearer, but since "Natural" will remain ungrouped I worry that might be less clear.

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

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

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.

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.

That is, I think we must choose one of two confusing behaviors when a user drags a "Wishlist" task into the "High" priority group:

1. Reprioritize the task.
2. The task mysteriously vanishes (actually, is placed in the "Wishlist" group in the same column, but that group is offscreen some of the time).

We could choose behavior (2) instead, but I think that may be worse overall. Is that what you're suggesting -- that we always do behavior (2)?

I'm suggesting removing it until T10333

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

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 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.

@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

LOW
T1
T10
Normal
T2
T4
HIGH
T3
T5
T6
UNBREAK
T7
T8
t9

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).

Yes first issue is that people are unware of it. Then even when knowing it you tend to forget it (it's not intuitive).
In fact the behavior I think users expect is that when move for a col to another the task just get placed at the right position according to its priority (if sorted by priority of course) and not the other way round (the position sets the priority as it is today).

In T8135#195972, @johnny-bit wrote:

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

Even though I understand your idea, it would not really help I suppose. The thing is, as @olivier-squid wrote in T8135#195980 people are not really aware of that feature. Having those columns is only a second way of showing priorities, it's redundant.

Most of our users are developers and even they are not fully aware of all the magic that happens with them knowing about it. I mean, how often do you actually want to change the priority for a task that you move into progress or review? They are usually not connected. I can understand though that this might be a big feature for some people. Maybe a feature switch or something like that?

Our developers keep changing priorities that the product owner set earlier and that's really not expected. 🙈 So, a big +1 from me on removing / reworking that feature. 👍