Page MenuHomePhabricator

Changing Workboards should generate a transaction
Closed, ResolvedPublic

Description

When a task is moved to a new board, we should generate a minor transaction. For example, moving something to the "In Progress" board should update the task when that occurred. @epriestley mentioned not generating an email in such case.

Event Timeline

chad raised the priority of this task from to Normal.
chad updated the task description. (Show Details)
chad added subscribers: chad, epriestley, mbishopim3.

We also have this outstanding TODO nearby:

// TODO: We also need to deal with priorities, so far this only gets stuff
// in the correct column.

The column-move half of this equation is relatively simple, but it should probably be coupled with that part, which is a little more involved.

For priority, currently, when we change the subpriority of a task in Maniphest, we only record a transaction if the priority changed. That is to say, if you sort unbreak now against unbreak now, no transaction is ever written and the new subpriority is simply saved; if you sort something from unbreak now to some other priority a transaction is written and the new subpriority is saved.

Is this what is desired in the board view? More explicitly

task A - hi pri
task B - N hi pri
task O - Z low pri

if task A is dragged to position N - just above the first low pri task - it should stay hi pri. Dropping it there does not record a transaction and just saves the subpriority. If it is dragged to position O - just below the first low pri task - it should become low pri. Dropping it here does record a transaction and saves subpriority as part of that.

For workboard, I figured a transaction every single time, just like changing priority (not subpriority).

I think we should always record a movement transaction:

epriestley moved this task to "In Progress" on the __Design__ workboard.

But I think this transaction should not generate email or notifications, since it feels like it would be incredibly spammy if it did. Maybe I'm wrong about that, though.

In the case where the move also re-prioritizes the task, I think we should generate an additional re-prioritization transaction.

Ideally, the sub-priority stuff should move inside ApplicationTransactions too, although this is more of a purity thing. I don't think we should show, notify, email, etc., for subpriority changes.