But moving on the workboard is no update at all... It is null action.

"Last Update" is low level, and includes some actions which do not appear in the task history. This is expected.

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

Thank you for the quick fix! As for the fate of the misplaced tasks, don't worry, I'll deal with them.

I recall some other discussion about searching for columns

I'd like to add some additional color commentary on the request as originally stated: searching for column names. We have several cases where tasks will be on multiple workboards -- each with their own columns -- and people struggle with figuring out "what is going on?". For example, a task might have been tagged with two engineering teams (either because ownership is unclear or multiple people need to work on the task) and on two product management like boards. This causes more pain with goals that are larger and more complex and don't fit cleanly into normal processes (something extraordinary like "provide more than 9 desk slots").

It's also fine to not fix this, or just fix some of it -- the affected tasks shouldn't do anything bad or break anything, even though their state isn't totally consistent. They won't respond correctly to queries (e.g., querying for tasks in the milestone won't return affected tasks, since they aren't "really" part of the milestone anymore) but should behave normally other than that. So it's not critical to hunt down every single affected task.

Thanks for the report! This is a definitely a bug, and should be fixed later today once D15834 is reviewed.

Also, generally recommend Ponder or Conpherence if you have general questions about Phabricator. Old tickets may not be the most relevant.

Correct, you will find you can't delete much of anything in Phabricator, as an explicit design decision. Some items are destructible if needed via the command line, looks like Columns are, if you can fish around the database and find the PHID.

Sorry if I've overseen something... This means that deleting columns is not possible? I just added some columns for testing, and would like to clean up again to add the columns I really need. I have 5 columns, but I'll only need 3 - So renaming wouldn't be a workaround.

Wooo! I think this completely covers my old request at T9520: Allow Workboards to show a thumbnail image within each card. :-)

Looks nice! Looking forward to the future plans for it, in the meantime i have a question:
Feature currently seems to assume a certain width for images, and scales images up or down to fit. In order to help my cover-photos avoid scaling and look their best I would like to know what that width is.

Just more JavaScript.

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

We're currently using columns as lightweight "subprojects" - i.e. our Bugs project has a FIXME column for higher-priority bugs. Would the recommendation here be to just use a subproject?

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!

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.

ignore this - test

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

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

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

T10469 is probably the best solution there.

One followup request from D14935: Show the workboard column along with the project. Obviously there is a space vs information value tradeoff, but if workboard columns are relevant anywhere wouldn't it be in Workboards? This was feedback from one of our product managers who looks at many different workbaords, not just a single team's.

Nothing actionable here, since we don't plan on adding additional options.

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.

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.

To provide some context, until recently, the API was in bad shape. Basically, the first time we wrote an application we'd maybe write some application.whatever methods, which shared some code with the rest of the application but not all of it, and then the API and application wouldn't always get changed in the same way. This resulted in methods like repository.create which can do maybe 20% of what the web UI can, does it in different, inconsistent ways, and edits made by the API might look or work differently than web UI edits. In bad cases, they'd even do different policy/permissions checks. This caused many many problems for a very long time.

Thanks a lot for putting your time into replying to my comments. I am thinking squarely in the context of T6027, and was looking primarily at the bullet points here as a stepping stone towards that. i.e.

Changes like T10569 should probably happen first. This is likely to be very complex, and is probably not a good task for a new contributor.

Are workboards 'un-beta' now, and stable enough for it to be worth putting some work into this? I can't promise to have time, but I'm certainly interested in having a look at this.

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

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

See T10569#164546 also. We're tracking this in multiple tasks, probably don't need a third.

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

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.

Right now, the main concern is trained employees moving cards on the workboard and accidentally changing priorities (due to sorting by priority), so I agree that improving the UI would be the higher priority. In the meantime, perhaps we'll patch our instance with https://secure.phabricator.com/T8135#130563 to prevent the surprise priority changes.

Why are users who shouldn't be changing priorities doing it?

The concern that @magcius mentions is that we (Endless Computers) only want team leads to have permission to triage priority. We set that up by restricting who has access to forms that allow editing priority. But the priority-sorted workboard defeats that form-based protection. Is there some other way to configure who has the ability to triage priority?

See T10333 for plans to make dragging cards in sorted workboards more clear (and T8135 for additional discussion). Those UIs aren't as clear as they should be and we'd like them to be more clear.

We might still need this. We use priority aggressively for feature planning, and make sure only team leads can triage and adjust priorities.

T10599 asks for column move APIs, which are adjacent to this.

This is made difficult by the nature of dragging cards into sorted positions on workboards: if you drag a card between a 5-point task and an 11-point task, we need to give it some number of points between 5 and 11, break the sort order of the column, or fling the card to the correct position in the column, which may be offscreen. Currently, in the simpler case of priority sorts, users don't seem to expect any of these behaviors, and all of these interactions are confusing to some users (today, we change priority).

Follow-up comment not worthy of the description: I'm not sure if this should be provided for projects unconditionally, or only if the project 'uses' points (which sounds like an expensive query, or Yet Another Damn Setting™ for project owners to have to set).

See T10333

Not sure if this is the right place to request for this, in an earlier build, the cards have username of the task owner on it, which is convenient to do a quick search using Ctrl+F to find tasks by a particular username. In the latest stable build, usernames on the cards are replaced with user photos instead, which makes Ctrl+F by username impossible. I understand that "Advanced Filter" is a workaround, but it is less convenient.

Regarding the space tags take up on workboard cards - would having tags without names (just icon/color) be hiding too much?

Yeah, it was complex enough that I didn't want to suggest an outcome design too strongly. :-)

This is probably at least somewhat reasonable, and we do something vaguely similar in the Maniphest list view.

whoopsies

See also:

Thanks for the discussion and for improving the clarity of my request.

I expect we'll do this eventually, but probably not until Workboards v4.

I do agree that commenting is usually done after reviewing the existing history. The concern expressed to me was that the extra navigational steps to get back to the workboard after commenting on a ticket were less pleasing than simply having a popover close. The only real reference I've got for this is that Trello allows viewing of the history and commenting within a popover... not that that is any justification unto itself.

Basically, like @cspeckmim suggests, commenting without context isn't something we plan to add. We feel commenting when you make a edit, or commenting when reading the entire task are the two most common needs.

I believe you can enable commenting through EditEngine (Maniphest Form Configuration). Beyond that we have a rough "idea" of being able to embed any Phabricator page inside a dialog, which is a non trivial amount of work with Quicksand

If I comment on task I almost always need to review the previous comments made. That would mean loading the entire task comment/history into a dialog which doesn't seem meaningful. The only case for "commenting from a dialog" that I can imagine is if you need to poke it for an update without seeing previous history - doesn't sound like a strong use-case. Creating/editing is modifying the task state vs. the discussion happening on the task, which makes a little more sense to have in the context of a dialog/popover.

Let me know if you hit issues -- it should just be better in every way than maniphest.query was, but I might have missed some data or something like that.