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.

Can I make a question?

An example.

No, I do not work together with @dtf, but I guess we have a similar workflow.

Thanks for your feedback! As you said it might be very complex to automatically sum up the points of all sub tasks. Of course this would be a very nice to have, but it was not my intention to request this quite complex feature. For us a "simple" UI change would be absolutely sufficient. It would be great to see the points of all sub tasks in the Task Graph at a glance.

Thanks for your feedback! As you said it might be very complex to automatically sum up the points of all sub tasks. Of course this would be a very nice to have, but it was not my intention to request this quite complex feature. For us a "simple" UI change would be absolutely sufficient. It would be great to see the points of all sub tasks in the Task Graph at a glance.

You should already be able to use custom forms to limit access to advanced fields by user, as we do on this install. If you (a user who is not a member of Community) try to create a new subtask here, I believe you will find that you can not access fields like "Assigned To" or "Priority". However, members of Community can.

Well, we do use Workboards and Milestones, Subprojects, but we'd like to have that feature. We have multiple custom fields configured, which are relevant to different parts of the team. I would like to be able to configure different sets of forms for those subteams so our newcomers don't break things they don't yet understand or shouldn't touch.

T12278 suggests that "sprint tasks" are being used in this workflow -- not milestones -- and "backlog tasks" are being used -- not columns. But this task also mentions columns and workboards. A more detailed description of your workflow would be helpful in understanding where the intended tools (milestones and columns) are falling short.

Why do you create backlog tasks or sprint tasks instead of using Columns on Workboards or Milestones in Projects?

I don't think this is necessarily unreasonable, but I'd like to see significantly more interest in it from other installs before we pursue it.

Unfortunately, this doesn't seem to be moving toward an upstreamable feature request which completely describes a root problem. I'm not sure how we can make what we're asking for more clear. We've already spent a significant amount of time on this and need to move on to other things.

Wikimedia ran a vote to find which problems are the most annoying to developers (not limited to problems with Phabricator) and this one was the most voted by far, with over one third of the participants voting on it.

ooh, sorry. I believed that the linked task is an example. Ok, there is a ticket for it. Subscribed.

Did you try reading the task I linked above?

But I don't want a new photo. I want to remove the photo.

Drag a different photo on top of it.

Yes, from this site. If you click here Abuse and search for task T7593, you see there is an image attached to the ticket in the Workboard. If you edit the ticket, you don't find something like {Fxxxx}.

Is this question about a specific task on this site, secure.phabricator.com, or some other site? Your question does not contain enough details to give you an answer.

Here is an example of a report that is satisfying several use cases from the comment above, https://secure.phabricator.com/T10339#159098. Those use cases, fleshed out a bit, include:

More use cases:

Hi Evan,

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.

• Why do you track "percent complete"? What do you use it for?
• Is it actually accurate? Developers are notoriously bad at estimating project timelines, so I would naively guess that a "Percent" field would have almost no relationship to reality.

How do you suggest we handle reports/feature requests that have not been properly filed per our guidelines. Currently you've opened 4, and likely all 4 have not met our guidelines. Our guidelines are based on what it costs us (2 developers, unpaid) to give a basic level of free support to anyone. Without some base guideline, we become overwhelmed with support and are unable to move the project forward.

Humm I'm sorry but it's not a support question. I think It's a feature request o even a bug...

This isn't a valid feature request. See Contributing Feature Requests and Describing Root Problems for what we take into the upstream. Specifically this needs a root problem described.

Unfortunately we don't take support questions as feature requests. See Support Resources for more information.

Not really.

I think T4316 is probably the best solution here, without knowing more about your user's workflow.

OK, I understand, I tried it several times... thanks for your time.

See Describing Root Problems if you need help defining the root problem. We don't take "feature does not exist" as a reason to build something.

The root problem is that I have created a custom field and I cannot modify it's value from the "Add Action" menu.

You have yet to provide a root problem

Sure I read them before posting anything!. Sorry I can't see what's wrong?

Sorry I'll try to describe the problem better.

Have you read the articles I linked?

Sorry I'll try to describe the problem better.

The information provided in this feature request doesn't provide the upstream with enough information to move forward. Please read Contributing Feature Requests and Describing Root Problems carefully and be sure follow all required steps before filing a task. We always require a root problem with every task.

I know I can create a custom field with the select type, but the problem is that I have 10 different products (project tags) and each one has 100 milestones (2.0.1, 2.0.2, ...). You can imagine why I can not use select for this...

Custom fields already support select type, and also allows searching by it:

{
	"company.foundin": {
		"name": "Found In",
		"type": "select",
		"search": true,
		"options": ["version 1", "version 2"]
	}
}

search interface:

Thank you for your quick reply. Indeed, this is tricky. Apparently, max-width has to be set on cells for overflow to work.

With text-overflow: ellipsis; and no truncation:

Phrequent is a prototype. We do not accept feature requests for prototypes, see User Guide: Prototype Applications.

I was able to reproduce this locally -- or something close enough, at least -- by recreating the simpler graph in T12114#207542, so I have enough to move forward.

I'm only trying to help you improve your own software - I have no personal interest in this issue being fixed. Imposing barriers on people taking a brief moment out of their day to draw your attention to bugs in your software seems counterproductive. If you choose not to accept reports of bugs that are backed up by a screenshot clearly showing the issue, then that is your loss.

For the records, Version info for that downstream instance says:
phabricator ef44831309df7b8d4b75ab653d1cd22813147c85 (Dec 16 2016)
arcanist 9c8774f9d30b921f0e4a5a10b98a7820517789a6 (Nov 10 2016)
phutil 77ace948f90c1003c2917175eb0a93c158023bdc (Nov 15 2016)

Finding version information seems non-trivial if you're not an administrator of the Phabricator installation. We appear to be running 0426ce73f0e63f1900f1cc285cfa1465ea72317e.

Please read and follow Contributing Bug Reports. This isn't a valid bug report and won't currently be accepted as is. Specifically we require version information of the install and steps we can follow locally to reproduce the issue.

I'm going to merge this into T7076, which discusses revisions instead of commits/audits, but the resolution for both is likely the same and that task has a more complete discussion of context.