Page MenuHomePhabricator

Priority grouped tasks doesn't handle task being set to priority outside grouping
Closed, WontfixPublic

Description

Reproduction steps:

  • Call up "assigned filter" (owner = you, grouping = priority)
  • change a task from priority X to priority Y, where no other task has priority Y

EXPECTED

  • task gets priority Y and new bucket for Y is formed

ACTUAL

  • task gets priority Y but hangs out in bucket X; no bucket Y is formed

Event Timeline

btrahan created this task.May 7 2015, 8:24 PM
btrahan raised the priority of this task from to Needs Triage.
btrahan updated the task description. (Show Details)
btrahan added a project: Maniphest.
btrahan added a subscriber: btrahan.
epriestley closed this task as Wontfix.Jul 28 2016, 10:24 PM
epriestley claimed this task.
epriestley added a subscriber: epriestley.

I think this is possibly undesirable to resolve in the general case, e.g.:

  • Order by date updated.
  • Go to page 2.
  • Edit any task.
  • "Expected Behavior": task vanishes, since it's now on page 1.

This behavior probably isn't so great. The easiest way to get this behavior would be to un-AJAX this UI and just reload the page, which sort of partially moots AJAX editing.

In practice, I think workboards have become more useful and more AJAX editing is happening there, and T10333 is probably the more practical version of this now. I also don't recall non-developers reporting confusion with this, so this might not be much of a real issue that users hit. I'd possibly favor just making "this task is dirty and might be elsewhere and/or not visible if you reloaded" more visible if they did hit it. T10333 may also give us some better tools for setting expectations.

Upshot: I'm not planning to do anything about this until some user hits it after T10333; if that happens, we can figure out what to do then. Possibly "more obvious dirty state" or "remove Ajax editing from task list". Probably not "rebuild the whole task list on the client", but who knows.