Page MenuHomePhabricator

Project templates/Copying tasks
Open, WishlistPublic


Phabricator is rapidly replacing our current PMS. We love it!

We have a lot of tasks which recur for most of our projects. For example a pre-release "checklist" task, populated with subtasks that need to be done before a release.
This could easily be extended in multiple use cases, like a task containing what to be done after client feedback concerning a mockup and so on.

Possible solutions

  1. When creating a new project, have the option to choose another project as template/base, which results in copying all tasks, ... This way, one could create a project "Default project", containing all default tasks.
  2. Possibility of copying/duplicating a task, although a method of copying multiple tasks in one single action would be desirable.

Event Timeline

robarov raised the priority of this task from to Needs Triage.
robarov updated the task description. (Show Details)
robarov added projects: Maniphest, Projects.
robarov added a subscriber: robarov.
epriestley triaged this task as Wishlist priority.Feb 6 2015, 1:23 PM
epriestley added a subscriber: epriestley.

You can use the template parameter to prefill a new task with some of the fields of an existing task. There's some discussion in T3320. This isn't really exposed in the UI and isn't a perfect fit, but you might be able to create a single template task and then bookmark the URI to create a new task based on it (or put that URI on a dashboard or something).

I imagine that the "Create Task" menu item might eventually be a "Create Task..." item with multiple options ("Create Subtask", "Create Dependent Task", "Create Similar Task"), but we don't have any short-term plans to pursue this.

Using the template parameter won't copy everything, and we don't have a way to copy subtasks right now. There are some challenges here: copying a task and all of its subtasks may be copying an arbitrarily deep tree with thousands of tasks, and we don't have the tools to express that operation in a reasonable way in the UI (discussed in T5166) or undo the action, and fully undoing the action isn't possible (we can't "unsend" email, for example). This will also put things into a "bad" state (where tasks have mostly-indistinguishable copies in the system with the same visibility) until the copying user fixes them, which could be very confusing if it was used in an undisciplined manner. Generally, exposing this as a general-purpose tool feels like something that would be easy to make a mistake with but where detecting and fixing mistakes might be quite hard. Overall, we don't have any short-term plans to pursue this.

Can you walk me through your use case a little more? For example, are your subtasks really just a checklist of items that have relatively low complexity? Suppose we had a separate "checklist/workflow" app which let you define sequences of steps and then embed them in tasks -- would that cover your use case, or does each item sometimes need to be edited/discussed/reassigned?

(We don't have any concrete plans to build such an an application, but there are some use cases around QA and Operations where it might make sense, and it's possible that we may be able to come up with enough reasonable things we could do with it that we could justify building it in the future.)

Thanks for your clear response!

I understand it's a slippery slope, and if not thought out well would rapidly lead to an unmanageable state.

Regarding workflow/checklist app:
Some of these tasks are discussed, like a "News module" taks where functionality is debated.
Also, there is not really a full-on chronology. Some tasks are dependent on others (and thus marked as depending task).

The example of a use case you requested:
We have one project for each website/app/... we create.
Sidenote: There are other projects, functioning like tags (Easy, Delight, ...). Much like you do here.

So, when starting a new website, there are a lot of tasks recurring each and every time. Some examples:

  • Set up hosting
  • Register domain name
  • Collect resources
  • Check legacy browsers
  • Redirect old indexed pages
  • Set up analytics
  • ...

Most of these tasks have more specific subtasks.

I'm talking about 50+ recurring tasks here.
The template-parameter solution mentioned in T3320 would be a solution, albeit a cumbersome one.

Just popped in my head:
A real quick 'n dirty way to accomplish this would be to have one text area for mass-creating tasks, where you could type/paste a simple tree structure, like

  • Task 1
    • Task 1a
      • Task 1a sub
      • ...
    • Task 1b
    • ...
  • Task 2
  • Task 3
  • Task 4
  • ...

A bit like some CMS'es have to mass-create a page-structure.
It provides lots of flexibility, is simple and wouldnt put things "in a bas state".
This approach, of course has its shortcomings, like not being able to assign priority, user while mass-creating etc.

PS. Don't shoot me for coming up with this hack. I know this is by far the most elegant way to handle this situation :)

I actually think that hack is pretty reasonable -- it's probably not something we'd want to put in the upstream, but it could likely be built with an extension fairly simply after the next API update (you could create the tasks via the API today, but the API doesn't currently expose features for linking them to each other -- see T5873). I think it does a pretty good job of avoiding the problematic / accidental outcomes where a thousand duplicate tasks get created and no one realizes until it's already done.

If you have common cases like "new website", you could even have the template be like:

Site Name: [example.com______]
Template for Tasks: 
  - Set up hosting for {$sitename}
  - Register {$sitename} domain name
  - Collect {$sitename} resources

...etc., and then the extension could be smart enough to replace the variable in the template when it created the tasks, so you ended up with "Register", "Register" tasks instead of 100 copies of "register domain". And I could imagine letting the parser recognize @username to assign the tasks, etc.

(We had one similar idea kicking around a while ago which was "provide a way to quickly create a bunch of tasks if you're in a meeting", but I think that got mostly solved with Workboards and we'd probably want it to be a little more structured than a big text field.)

Given the use cases we've heard from other users so far, this feels a little too special-purpose to actually upstream, but I'll keep an ear out for other things which this might be a good fit for. I think it would be easy (a couple hours of work) to develop an in-house extension version of it after the API next gets updated. That API update is on our short-ish term roadmap, but it's behind a lot of stuff (we're focused heavily on launching our SAAS product right now, so most major product development is waiting on that) and I expect it's at least a month away and probably further out than that.

Great, works for me.
Will keep an eye out for the updated API in the coming months!

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.

Having to create these tasks manually for each project is a deal-breaker. Batch-creating them using a text area will push the maintenance of these tasks elsewhere. I don't really see a better alternative than simply creating a "template project" that can be instantiated or copied to create a new project. However, any other solution is welcome!

To clarify, this needs not be specific to tasks. It'd be awesome if the project menu can also be templated.

chad added a subscriber: isfs.
chad added a subscriber: chad.

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

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

Looking at the template etc. parameters (T3320), they cover a good chunk of what we need, so if it could be exposed in the GUI via a "Clone task" function or something, so we could apply any particular task of our choice as a template, it would make significant progress in solving our use case. It wouldn't deal with subtasks, so that difference in use case wouldn't matter. The main deficiency for our use case would be the lack of ability to concurrently edit the original task.

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

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.

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

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.

It's hard to say how much time this would save, because this happens most frequently in our content development, and our team size and allocation varies day-to-day. The saving may be modest, at something like 10 minutes a day. I think the greater benefit would probably be in removing the hurdles to doing this; we'd benefit from having our tasks better organised, because people would actually be more inclined to split them when they should. This would indirectly save a lot of time because tasks wouldn't be closed which are only half done and then have bugs raised which are tracked back to the task and then backups are checked to see if something went wrong with deployment, and then the proper status of the task is ascertained, etc., etc..

I personally would keep the tasks separate, as I think the concurrent editing requirement is the harder problem to solve. The templating aspect is already mostly done by subtasks and T3320, and adding a slightly modified clone task function would not be hard, I imagine. Much harder is allowing you to really split a task by being able to move material between the two tasks (original and new) on a single page or solving that difficulty some other way.

It's fine if discussion of this needs to wait. This isn't a huge problem, and even if it were, it's not up to us to set your priorities. But it's a problem we're encountering, and we'd benefit from solving it at some stage if possible.

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

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

Of course, it would be more valuable if the API were more stable, and ideally
something would eventually be implemented upstream that addresses our use case.

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