Go for it.

@epriestley any objection to removing the "disabled" look here for workboards and subprojects? It's not a consistent pattern with "no permission" we usually use.

In T12330#213674, @chad wrote:

Do you think it makes sense to grey out "Subprojects" at all or have a tab for it when there are no subprojects?

Do you think it makes sense to grey out "Subprojects" at all or have a tab for it when there are no subprojects?

Events stuff isn't on any roadmap, so it also could be years before it was modified.

Thanks for the pointer. I wondered if there was something like that I could hook into.

I think https://secure.phabricator.com/book/phabricator/article/events/#ui-did-render-actions still works, that you can build a "Clone Task" action on the side of your Maniphest links and have it use that task as a templateID. Might be worth fiddling with locally.

I don't have a problem grouping the use cases together, and it makes a lot of sense to solve as many use cases as possible per feature. I just wanted to point out the differences so that when this task progresses, it can progress with the different use cases in mind. At a first glance, I didn't think the use cases were very similar at all, as this is a lot about creating a bunch of tasks by template (or from a template project), which is a bulk action, really, whereas really our use case is about task micromanagement. However, on further consideration, there is significant overlap, especially from what T3320 brings to the table.

Though this task also talks about Project Templates so maybe we should have two tasks.

All of your use cases fall into this task, I believe. That being "I want a new task based on x, y, or z" We want to group similar feature requests together for planning reasons, so multiple root problems can be solved by a common, thought-out framework. I can't guess what the UI would look like, or if we'd offer anything else like you're mentioning. I appreciate the detail on the original task, but in general we're not likely to be able to get more into a discussion on a task thats several years away at best.

How much time per day do you expect this feature to save you?

I see there is some similarity, but some important differences in the use cases:

• We are interested in splitting a specific task, crafting the title and description in particular, manually (in fact, with quite a lot of care), whereas here the focus is on creating generic tasks, or templated tasks
• We would not want subtasks to be copied, I don't think
• We need to be able to edit the original task at the same time as creating the new ones, whereas there is no aspect of that in this use case

I merged this primarily for the "Create Similar Task" discussion above, which I think a similar enough feature.

More use cases:

This is an essential feature for organizations running many, similarly structured projects. For us, each project is essentially a workflow of a predefined series of tasks that need to be tracked, assigned, and discussed individually for each project. Of course, each project will grow its own, custom additional tasks, too.

T11036 will probably be the next round of changes, but I don't think we have this stuff on any immediate roadmap.

I think it's not perfectly clear in the UI, but we do have it documented:

That's up to you and your team.

In T12144#208351, @chad wrote:

I'd rather fix the core problem if it's an unclear typeahead.

I'd rather fix the core problem if it's an unclear typeahead.

My understanding is that subprojects are basically just regular projects but with a parent relationship. We didn't want these projects to pollute the projects typeahead because no-one should be creating tasks within these subprojects (given that these subprojects dictate what we are working on). By choosing "milestone" instead of "subproject", it becomes clearer in the project typeahead that the subproject is internal to the parent project. That is, if we made #our_january_goal a subproject then it would show up in the projects typeahead as "Our January Goal" whereas as a milestone it is rendered as "Our Team (Our January Goal)".

If the milestones aren't strictly ordered, why did the user create milestones instead of subprojects?

I'm going to merge this into T11580 because I think that describes what remains here.

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

One concern I have with this is that the largest sequential milestone may not be the "current" milestone. If you're currently in Sprint 4, someone may reasonably create Sprint 5 before Sprint 4 concludes.

Per above, this is working as intended. I'm open to implementing "Copy Columns from <Previous Milestone>" if anyone actually wants that, but it seems like I may have just made it up. Feel free to file a new task if you'd like to see it.

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

If you have project "AAA" with milestone "BBB", which renders as "AAA (BBB)" in the UI:

Actually, I think the issue @jcox reported and the downstream issue (https://phabricator.wikimedia.org/T152726) may not quite be the same.

It's also safe to cherry-pick whatever D17012 lands as and then reindex to pick this up immediately without doing a full upgrade.

For best results (or maybe "any results"), run this command after upgrading past D17012:

This search UI also needs to be updated:

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.

This feature request does not describe a root problem. See Describing Root Problems.

After upgrading and several weeks of the icons not disappearing,

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

In T5051#156552, @chad wrote:

...
This task will be re-scoped to just being about burn down charts for milestones.

who can help me?

Thanks, the patch definitely helps a lot in my case!

D16367 make the order consistent (instead of reversed) in the task list view and on workboard cards.

Ah, I didn't even notice there was a sorting criterion.

I don't think this is a sort stability issue: we're preserving the order which the user who entered the tags originally used (in this particular UI it looks like we actually use reverse order, which I'd consider a bug, but other UIs like the "Tags" in the rightmost column and when editing the tags via "Edit Task" we use the original order).

The reason we require it upfront is that it's a large support burden to ask for this information. It costs Phacility money. If users provide it upfront, we spend less time on support and more time building Phabricator. If you're a frequent contributor, this obviously compounds and make providing support even more cost effective. We just want to be able to provide everyone with free support. See also T9212 for longer discussion.

I don't know if this is a bug report or feature request. It's missing information for both. Please read and follow Contributing Bug Reports and Contributing Feature Requests for how to file stuff into the upstream. How can we make it more clear this information is always required?

Ah thanks, thought we did but couldn't find it since "subproject" was spelled "sub-project"

T11102 is identical

What about using the batch editor instead?