Page MenuHomePhabricator

Way to edit which column a task is in from the task itself
Closed, ResolvedPublic

Assigned To
Authored By
cburroughs
Sep 3 2014, 3:40 PM
Referenced Files
F1238494: 62812079.jpg
Apr 20 2016, 3:52 PM
F763129: mock.png
Sep 8 2015, 2:33 AM
F197979: boardlink.png
Sep 3 2014, 8:29 PM
Tokens
"The World Burns" token, awarded by cburroughs."Like" token, awarded by Luke081515.2."Like" token, awarded by manas-chaudhari."Like" token, awarded by simunekj."Like" token, awarded by jithinvmohan."Like" token, awarded by saper."Like" token, awarded by honza.

Description

Say we have an Ops board with: Backlog, Needs Info, Doing. I'd like to be able to ask a question in a comment and move the card to 'Needs Info' at the same time.

Backstory: Previously we used tools where you could do super complicated state diagrams for tasks: http://trac.edgewall.org/attachment/wiki/WorkFlow/Examples/enterprise-workflow.medium.png I'd like to instead try lighter weight ah-hoc (ie not enforced or global) states via workboards.

Related Objects

Mentioned In
T12074: conduit API extensions for subprojects and milestones.
T11036: Put subproject columns on workboards
rPcac26c882476: Fix errant rules for associating projects when dragging tasks within a…
D15834: Fix errant rules for associating projects when dragging tasks within a milestone column
T7820: Add "Closed, Duplicate" option to Status Action in Maniphest
T10638: A Task can end up on a Milestone workboard column without being in that Milestone
T5214: Add Conduit API methods for workboards
T9280: Support moving on a workboard when commenting on a Maniphest task, along with other actions
T7013: Support bulk transmission of notification frames in internal Aphlict protocol
Mentioned Here
T10912: Repositioning tasks within a Milestone column moves the task out of that milestone
D15638: Implement a rough optgroup-based "Move on Workboard" stacked action
D15639: Allow stacked comment actions to be explicitly ordered
D15634: Merge TYPE_PROJECT_COLUMNS and TYPE_COLUMN transactions into a more general TYPE_COLUMNS transaction
D15635: Render new more-general move transactions in a human-readable way
D15636: Expose column positions via maniphest.edit
D15637: Migrate old task transactions to use new display code
T5214: Add Conduit API methods for workboards
T10486: Error when creating a sub-task from a prefilled URL that includes `column`
T10599: Conduit - 「maniphest.edit 」when changing column, always throw「Validation errors」
T5474: Support workboard column triggers which activate when a task is dropped into a column
T9280: Support moving on a workboard when commenting on a Maniphest task, along with other actions

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Thank you for merging.
(Looked for relation "mobile" "workboard" but did not find anything related.
This is exactly the required solution, thank you and sorry for the duplicate.)

no worries! wasn't easy for me to find either

Would it perhaps be simpler if instead of developing a "Change columns" UI, actions can be added to move columns, something more along the lines of what I mocked up for T9280, i.e. a simple action with two parameters, rather than a monster action with parameters for all existing boards?:

mock.png (400×800 px, 27 KB)

If you want to move the task on multiple boards (which I imagine is relatively, if not absolutely rare) you would just add multiple actions. The order of the actions is clear, even if not mutable.

That would make this function at least useable in some way, even if it would be a bit complicated if a task has several (5+) projects assigned (which is, what you said already, very rare).

I would like to confirm that it would be a great addition to be able to move a task to a different column within the edit mode.
Especially if you're working within the workboard view, it would be efficient to not need to explicitly move the task to another column, right after the task has been edited within the inline popup (or vice versa).

The drag and drop is great by the way, but the move of a card from a long list to a short list, requires vertical scrolling for the correct column placement that it can be a tad annoying when actively used.

honza added a subscriber: honza.

It would be great to have this in Maniphest - whatever way there is...

In T6027#135704, @isfs wrote:

Would it perhaps be simpler if instead of developing a "Change columns" UI, actions can be added to move columns, something more along the lines of what I mocked up for T9280, i.e. a simple action with two parameters, rather than a monster action with parameters for all existing boards?:

mock.png (400×800 px, 27 KB)

If you want to move the task on multiple boards (which I imagine is relatively, if not absolutely rare) you would just add multiple actions. The order of the actions is clear, even if not mutable.

I think this is a great solution. Everything can be done with such a menu. Is anybody still working on it?

We recently switched from GitHub / HuBoard to Phabricator, and overall I'm really happy, but the one thing that I (and the other engineers on my team) sorely miss is the ability to change columns from within the task. It is really awkward to comment on the task but not be able to change columns without swiching back to the workboard.

My personal vote would be for an implementation tied to the "Add Action..." menu rather than "Edit Task", as the typical use case for this would be to add a comment as part of the action to move the workboard column. (But, I'd happily accept an addition to the "Edit Task" UI if that was somehow easier to implement.)

FWIW, it would be great if custom fields could also be edited from the "Add Action..." menu, but that is lower priority for me as they don't change anywhere nearly as often as workboard columns.

Is there any chance that this feature will be implemented sometime soon?

Is there any chance that this feature will be implemented sometime soon?

See Planning for information on timelines.

chad set the point value for this task to 1.675.Mar 17 2016, 11:53 PM

@epriestley, I'm not sure if/when I'll have time, but would a patch for this along the lines of my previous comment be considered? I'm conscious it must be forward-looking to T5474, and might take a few attempts for me to get up to standard. If the core team can review/guide me, I'm certainly willing to give it a go as time permits.

No, we're not open to implementing this as multiple separate select controls. We don't really have a UI in mind that we're happy with, but we have several we're less unhappy with than multiple select controls (leading contenders: single optgrouped select, alternate actions menu for workboard actions; possible contenders: visual table-layout control, select per-project in a dialog).

Any implementation here will run into at least two moderately complicated pieces of infrastructure:

  • Maniphest actions are generated by EditEngine fields, which also generate the edit form and API.
  • The TYPE_COLUMN and TYPE_PROJECT_COLUMN transactions do not gracefully accommodate this edit and are un-graceful in general (see, e.g., T10486 and T10599).

The minimum implementation must deal with these, and I believe they're not trivial. For example, we currently have no other actions which generate an "Actions" item but do not generate a control on the Edit form, so EditEngine would need to be expanded to support this.

Thanks for the guidance. The exact UI is a minor detail. I'm pretty happy to contribute towards either of your leading contenders (and don't like either of the possible contenders much). But as you say, that's not going to become an issue until a little while down the track.

I'll see if I can find time to lay some groundwork. Would it be true to say a good starting point would be Conduit API for these operations from T5214 and T10599?:

  • get the name for a column given its PHID
  • get the columns for a project
  • get the tasks assigned to a column
  • move task between columns

Evan basically answered my question in T5214. There are good reasons not to expose an API at this point, as due to possible future changes, it might be unstable. I'll try to figure out how to do these things within Phab only, perhaps by creating myself a temporary outdated-style API. Then I'll to understand the second bullet point above more fully. I'm pretty comfortable I understand the point made about EditEngine.

epriestley removed the point value for this task.Apr 6 2016, 8:30 AM
epriestley added a project: Prioritized.

Does this being added to 'Prioritized' mean Phacility are working on it, so
there's really no point in me plodding along trying to do it? :-)

Yes.

I'm going to sort out the infrastructure issues first, then we can see where the UI goes. Specifically:

  • The handling of the TYPE_COLUMN transaction has bad edge cases (T10486) and this transaction type probably should not exist at all.
  • The format of the TYPE_PROJECT_COLUMN transaction is also probably sort of nonsense; at a minimum, it's not well-suited to expose in the API (T5214).
  • The interaction between these column edits and project edits is not currently very sensible.

The infrastructure changes should now be complete, and we're clear to start experimenting with the UI. Progress so far:

GoalRefsHoursNotes
Update InfrastructureD156341.5Unearth technical debt in existing transaction logic.
D156350.5New transaction rendering.
D156360.5Sort out API access to new transactions; fix T10486.
D156370.5Migrate old transactions to new format.
Subtotal3 Hours
Cumulative Total3 Hours

Alright, a v0 of this is live here now -- "Move on Workboard" in the "Actions" menu above the comment box. This is a rough cut and we may not keep it in this form, but the infrastructure it needs is built now, at least.

If you play around with this, let us know if you spot issues or have feedback. Otherwise, we'll probably let it sit for a couple days and see if we hate it or not before deciding if it needs a different treatment.

Other stuff to look out for:

  • This affected all moves (including drag-and-drop and create-directly-in-a-column), so it's possible stuff on those workflows got some new bugs as a bonus. Yell if you spot any.
  • All old transactions migrated as part of this, and it's possible that isn't quite right. This would present as transactions about column moves rendering weird. I don't immediately see any issues on this install.

Log update:

GoalRefsHoursNotes
Minimum Viable InteractionD15638, D156391Basic optgroup action.
Subtotal1 Hour
Cumulative Total4 Hours
chad moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 6 2016, 4:56 PM

I've upgraded our instance now this has hit stable, and our team is thrilled. The interface may not be perfect, but it satisfies the vast, vast majority of our use cases. Thank you!

Is adding a new project tag and "move on workboard" in the same set of stacked action a minor extension, or super hard?

cburroughs moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
epriestley claimed this task.

This isn't the most thrilling UI but seems to get the job done. T10912 covers one minor followup issue.

If you want some followup feature, file a new task and we can sort things out there.