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?:

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.

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?:

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.

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

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:

ignore this - test

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:

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?

Just more JavaScript.