I'm going to merge this into T11036, which specifically describes subproject columns.

Yes, triggers sound like they'll do the job. Not to say search and filterability still wouldn't be handy in more ad-hoc cases. Triggers require foresight.

If triggers (described in T5474) would not solve your problem, feel free to file a new feature request describing your problem (see Contributing Feature Requests, Describing Root Problems) and we can discuss approaches.

I think when one searches for something, or filters by something, that something does not need to have a "special meaning". Searching for "sandwich" does not require Phabricator to know or care what a "sandwich" is.

I think this is actually for the primary task lists, I just didn't do a good job of describing it. Here are more specific reproduction instructions:

@joshuaspence: Did 'per column scrolling' fix this issue? Asking as I have not experienced this problem in Firefox lately...

Thanks.

Since this is a highly desired feature for us and many other Phabricator users (tokens, tokens, tokens), I would really like to contribute. I already did some work and it turned out - thanks to the flexible architecture of Phabricator - not that much is needed to get something quite nice and robust:

• A typeahead datasource for project columns
• A new Herald field for task cards
• A new condition type in HeraldAdapter class
• Minor extension of the project column query class

Please see and follow Contributing Feature Requests for what information is required in a feature request. Specifically we only take requests that state root problems, not just that a feature is desired.

+1 - quickly adding several tasks to a given column does currently feel quite tedious

I believe that using phid.query should be helpful.

In T5523#185944, @dariusz wrote:

my expectation would be: have "Move to Workboard Column" available in the "Bulk Edit Tasks" actions.

@raincoastchris the context of this issue caught my eye because I've really wanted Phab to generate a cumulative flow chart and Kanban statistics for some time now. I took a stab at it today and modified an existing python script to generate a cumulative flow chart and Kanban statistics (https://github.com/lyahdav/analytics-limn-analytics-data/tree/kanban_stats) but configuring it is a bit painful because there is no easy way to get the names of all the columns in a workboard right now.

I tried to rephrase slightly to clarify the root cause rather than looking for a solution.

• T6064 already covers creating tasks with one click instead of two.
• T10946 covers using EditEngine templates on workboards, I guess. That task is pretty iffy, too. This could probably use a separate, more focused task -- @cspeckmim, if you want to file one describing your use case in a little more detail I can merge T10946 into it if I don't have better ideas for you. (I thought I saw one more of these somewhere while dredging through the backlog to populate Contributor Onboarding but I wasn't immediately able to find it.)
• We don't currently plan to implement a distinct inline quick edit mode like Trello.

Sorry, I missed the thread on this.

A potentially less controversial fix for the 2-step entry issue might be to add a keyboard shortcut that will add a task to the last used column.

Just want to +1 that this would be a very useful feature for us. I think our usecase is similar: We have a lot of teams (especially ops teams) using phab workboards and columns extensively. Rather than try to shoe horn different types of reporting, etc. into phab they are relying on external systems/tools, but it is pretty painful to extract data on what column tasks currently live in.

Would this apply to having ability to set an edit/create task template as default for a workboard/project? This recently came up in discussion the other day where someone wanted tasks made for a workboard/project auto-inherited permissions. My mind turned to making a new Create task template with the permissions they wanted, but it didn't seem there was a way to set it default to a project. It sounds like this task touches on similar area?

I agree that there *shouldn't* be any extra cost purely owing to having more fields if I'm only editing one and it is default-focused, but I'd argue that having a more complex form will still slow humans down (at least initially).

There is no actual cost to the form having more fields though, right? It doesn't actually slow you down, it just "feels" more complex?

Is this really "Make Workboards look and feel exactly like Trello"?

It sounds like you really want Workboards to work exactly like Trello, not just to be able to customize the form? That is, if we let you simplify the form down to this:

More fields means

Why does having more fields make creating a task slower? I'm not able to create tasks any more quickly using a form with fewer fields.

@epriestley Here's an anonymised version of a live workboard. I've completely wiped out all identifying data; I thought about summarising the task titles rather than obliterating them, but afraid I lost the will to live at some point.

Starting to try out Workboards (we're coming from Trello), and I felt the absence of this feature as well.

Slightly easier is:

I was able to reproduce this, possibly, by following these steps:

I would also maybe check webserver error logs, too. OS/Browser might help to know as well.

In T6502#187499, @dpaola2 wrote:

We have no precedents of abuse in Phabricator so far, but looking at our history with Bugzilla I will not be surprised the morning we find a first precedent.

^ I am incredibly jealous of your perspective and am really, really surprised you haven't had this problem yet!

How can we make the title and description more clear?

Hi Chad,

any customization.

Does this ticket request include displaying Status of each Task on the Workboard display?

For what its worth, the biggest violators at my company tend to be company executives who (sometimes) rightfully wish to skirt our process. But, when they see how trivial it is to skirt our process, they're tempted to do it more often. And then they do it more often.

For completeness, I'll also drop a mention of T5024 here, although I'm not yet sure how the two might tie together.

@epriestley Yeah, that would certainly be really useful for some cases; I imagine infrastructurally it'd be a good step towards this as well, along with T10569. I don't think it would help this particular usecase though.

Oh, I forgot to mention this but T10333 (groups within columns) is another possible attack here, and one I definitely intend to implement regardless of other work and outcomes (e.g., T5474) since I think it stands on its own and is already well-justified by confusion with priority-ordered boards. T10333#158767 has the ASCII-art mock:

@Danny_B I am curious about your actual root problem as well. I have heard this from some end users but have yet to get a clear use case. Can you give an example of how you are using your workboards that this is a problem for you. I understand "too much email make it stop" however that is not something that is actionable and very short sighted.

In T4863#152912, @epriestley wrote:

• Diff/Mock: These are fairly straightforward, alhtough I'm not totally convinced that they're valuable. At least in my personal workflow, I don't imagine I'd be likely to ever use them, and I don't recall other requests for them offhand. I'm hesitant about building new hard-coded first-party application stuff, too, since we've made so much progress on getting rid of it. I could build this in a generic way, of course, but that makes it less straightforward.

I understand a high level problem of "i get too much mail when watching a project", but I don't really have a picture of the specific "root problem". We don't really want to guess why a specific column is more interesting. Knowing the background of the project and columns might provide some insight. Maybe they need to "sign off" for instance in anything that comes into a specific column, like "QA". We just don't know, so it's hard to understand what the correct upstream solution is without these details.

I don't have any idea where further/deeper to go than to what I already described in the description:
User is not interested in being notified about all tasks of the given tag, but only on those which are in particular column.
If you ask "why", I can imagine perhaps "I don't want to be spammed by things I am not interested at".
Perhaps might yet be worth to note, that it obviously applies to boards sorted by categories/area, not progress-wise (Kanban).
I can also assume it is related to discouraging of "tracking tasks" (ie. due to many issues with task graphs) which are typically exactly equal to such workboard column - they "monitor" certain area of the project, so user is subscribed to them, but not watching the entire project.
I don't know what to add more. Better if you ask.

You should see this information about the feature request form:

@Danny_B Are you aware we don't take feature requests that omit root problems?

I imagine this task is easier now that we have a "Move on Workboard" selector.

In T5024#59425, @epriestley wrote:

For the first case, maybe a column permalink would be a better solution? Then you could navigate back up the board easily. We can structure this as a search query instead (and it might not be bad to make that possible, for Dashboard panels) but it will lose some context. There's also no control which will easily let you select a column right now, and building a nice one is probably a fair bit of work (plus, it overlaps a lot with some other less well-defined tasks and infrastructure-blocked things).

hey all,

Click "Try Free" then click "Test Instance" after signup.

$20 to use Phacility?

I'll re-test on our private network w/ latest phab soon, who knows maybe it's fixed.

All I needed to test on my home comp's ie as well was access to a 6 column workboard here, but I felt paying 20$ to use phacility was a little steep to keep the bug open.

Can't find a means to reproduce this locally and haven't seen other reports. Can revisit if either of those change.

This would be a massive workflow improvement for us

Closing this out since I don't think this is something we'll want to pursue (less flexible workboards).

Right, so I can make a parent task "Launch Product" and have subtasks of "Build Product", "Write Marketing", "Contact PR". All of these subtasks live on different workboards on different columns.

A big issue here is about terminology: Phabricator doesn't actually have a "sub-task" object; The "Create Subtask" button creates a "regular" task, that's Blocking the "parent" task.

Phabricator Tasks aren't trees, and aren't tied to an individual project or column.

Roughly, I think T10333, T5474, and T4863 are leading the way to making boards more magical and PM friendly. I would want to continue on and build those first and see if most of what you want could already be accomplished with those features. Since this request is mostly hypothetical, I'm going to close it out for now and we can revisit things down the road.

I think we've shot down other requests in this vein (Herald + Workboards) due to overwhelming interest in T5474, which would likely be prohibitive or insanely complicated to support if Herald was in the mix.

Sorry, the Root Problem would be something like:

This seems related to T5474: Support workboard column triggers which activate when a task is dropped into a column.

I think anything automatic here would likely only be truly correct maybe 50% of the time, and I think that's really bad from an accuracy perspective if that's what's important to your company. I'd rather look at what information is actually missing from the workboard cards (ie, diff attached) and explore options there.

I don't understand the root problem this is seeking to solve. Please read Describing Root Problems carefully and try to follow the instructions there to describe a problem we can solve.

Third-party applications which assume dateModified means "last 'meaningful' update" are written incorrectly. It does not mean that, it is not documented to mean that anywhere, and it is clear from the code that it doesn't have this behavior. It is unreasonable to assume that the only possible purpose of this field is metric extraction. This field is a low-level field which serves a different set of goals. It explicitly does not serve metric extraction goals.

In T10989#176079, @Danny_B wrote:

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)

In T10989#176072, @epriestley wrote:

These are third-party extensions, not other upstream applications, right?

Yes.

Why do you consider this to be a bug in Phabricator rather than in those extensions? Does the documentation say "this field is updated only when a 'meaningful' update is made to an object, and you can and should rely on it to have this behavior when extracting data from Phabricator" somewhere?

It's logical - you can not build reasonably working application on wrong dataset. One would assume, that maybe in future, Phabricator (either directly or via an extension) will have support for such stats too (as it currently already has some stats such as burnout charts or so...)
Inability to do such stats due to unreasonable dataset below makes Phabricator (otherwise good application) useless for teams which are trying to improve (read: shorten in this particular case) the task life-cycle - and that's pretty much every team since noone wants to have long time untouched tasks without any action taken... ;-)

In fact it breaks various monitoring/statistics depending on last update