Feature #973

Assign different status sets and workflows for separate projects

Added by Clyde Goffe about 11 years ago. Updated 11 months ago.

Status:NewStart date:2008-04-02
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues workflow
Target version:-
Resolution:

Description

Hey,

Currently it seems the statuses and workflows are system wide settings.

It would be good to have the flexibility to create multiple status sets along with their accompanying workflows. Then assign a set of statuses+workflows to their respective projects. This can be in addition to an already defined system wide setting that can be overridden if necessary.

This is in the event a team working on a particular project has statuses and workflow needs that are different from the rest of the organization or team members of other projects.

I haven't seen a way to accomplish this in the current version. If its already available can someone please tell me how to do so.

Thanks,

Clyde


Related issues

Related to Redmine - Feature #1853: Make Projects truly independent of each other New 2008-09-04
Related to Redmine - Feature #3726: Trackers per Role Closed 2009-08-10
Related to Redmine - Feature #2905: Enable per-tracker issue status set Closed 2009-03-05
Related to Redmine - Feature #1966: Different set of Issue Statuses per Tracker Closed 2008-09-29
Related to Redmine - Feature #2240: Ability to constrain tracker by role Closed 2008-11-27
Related to Redmine - Feature #285: Tracker role-based permissioning Closed
Related to Redmine - Feature #4828: Dynamic / modular workflows. New 2010-02-13
Related to Redmine - Feature #10331: Per-project 'Issue Closed' status customization New
Related to Redmine - Feature #7839: Limit trackers for new issue to certain roles Closed 2011-03-11
Related to Redmine - Feature #5991: Tracker should have it's own default issue status Closed 2010-07-29
Duplicated by Redmine - Feature #6436: Ticket Workflows as independent entities. Closed 2010-09-20
Duplicated by Redmine - Feature #10039: Issue statuses for each project Closed

History

#1 Updated by Clyde Goffe about 11 years ago

Is it possible to plan this for version 0.8? Is it even feasible at this point? Is it too much of an architecture change?

The lack of this feature is the only thing that's preventing my company from taking a serious look at Redmine.

#2 Updated by Mischa The Evil almost 11 years ago

+1 :)

#3 Updated by Thomas Pihl almost 11 years ago

I use a very crude homemade "fix/patch" to work around this. I create different statuses and workflows per project/tracker. It ruins some of the nice summary features with some 90 different statuses (eventually i might be able to filter that as well).

I prefix workflow-name and status-name with some identifier. I have added a filter-field when creating/editing workflows to avoid the huge matrix otherwise loaded/viewed.

I would prefer not to show my changes since i'm still a novice in rails and my patches are all but rubyish (but i am learning). Default status has another crude fix needed so that users start with a status valid for that workflow.

It's dirty but working for my users at this point in time.I REALLY vote +1 for a good solution to this feature.

/T

#4 Updated by Eric Davis almost 11 years ago

Thomas Pihl wrote:

I would prefer not to show my changes since i'm still a novice in rails and my patches are all but rubyish (but i am learning). Default status has another crude fix needed so that users start with a status valid for that workflow.

It's dirty but working for my users at this point in time.I REALLY vote +1 for a good solution to this feature.

Go ahead and post your patch. It might help someone else and others could improve on it to make it more rubyish.

#5 Updated by Clyde Goffe almost 11 years ago

I agree with Eric. Please post your patch. Hopefully it will be improved upon and will become an official patch and slated for a future release.

#6 Updated by Jim Jones almost 11 years ago

+1 for this feature.

We are in the same situation. We'd love to manage all our projects with redmine but many projects have drastically different workflows.
For now we've settled on using redmine for the programming stuff and another tool for the rest - but obviously that's a less than ideal solution.

#7 Updated by Brock Gunter-Smith over 10 years ago

+1
Redmine should ideally allow setting master workflows and then override them at the project level if required.

#8 Updated by Harry Yamamoto over 10 years ago

Thomas Pihl wrote:

I use a very crude homemade "fix/patch" to work around this. I create different statuses and workflows per project/tracker. It ruins some of the nice summary features with some 90 different statuses (eventually i might be able to filter that as well).

I prefix workflow-name and status-name with some identifier. I have added a filter-field when creating/editing workflows to avoid the huge matrix otherwise loaded/viewed.

I would prefer not to show my changes since i'm still a novice in rails and my patches are all but rubyish (but i am learning). Default status has another crude fix needed so that users start with a status valid for that workflow.

It's dirty but working for my users at this point in time.I REALLY vote +1 for a good solution to this feature.

/T

Yes,like workflow-name and status-name for grouping the workflows and statuses...
Hope the patch...

#9 Updated by Stephanie Collett over 10 years ago

+1 We would heavily use this feature if available. Right now our PMs have to settle on one standard, but they frequently ask for more flexibility.

#10 Updated by Enderson Maia about 10 years ago

+1

Thomas Pihl wrote:

I would prefer not to show my changes since i'm still a novice in rails and my patches are all but rubyish (but i am learning). Default status has another crude fix needed so that users start with a status valid for that workflow.

Make your patch public, so others can contribute.

This feature wuold be great for me, co I can use Redmine for evereyone, and not just the dev crowd.

#11 Updated by Haomin Liu about 10 years ago

+1
I've just proposed a duplicated ticket #2905 for this feature. It would be really nice if we have it in next version.

#12 Updated by Krzysztof Szalast about 9 years ago

+1
I also need that feature

#13 Updated by Alexander Usikov about 9 years ago

+100
Actually we can't use redmine because of lack of this feature

#14 Updated by Nikolay Kotlyarov about 9 years ago

+1

#15 Updated by Raphael B almost 9 years ago

+1

#17 Updated by Brent Shaffer almost 9 years ago

+1. This would be such an amazing feature.

#18 Updated by goldleaf asd over 8 years ago

SPAM

#19 Updated by goldleaf asd over 8 years ago

SPAM

#20 Updated by Ryan Cross about 8 years ago

+1

#21 Updated by Etienne Massip about 8 years ago

  • Category set to Issues workflow

#22 Updated by ee se about 8 years ago

+1

#23 Updated by Overmind Eternal Will about 7 years ago

+1
Also for my company this feature is blocking the adoption of Redmine for our workflow. :(

#24 Updated by Patrick Feistel over 6 years ago

+1

#25 Updated by Kenichi Handa over 6 years ago

+1

#26 Updated by Daniel Felix over 6 years ago

Hi there,

I think this would be a great feature!

Some suggestion would be to remove the workflow and ticket status menulinks from the administration panel or define them new.
The new implementation could be something like this:
  1. Per project settings, each projectmanager can define trackers with a workflow set for this project. They can also add trackers, which already exists (to prevent hundreds of "bug"-trackers) and redefine a workflow for their project. The workflow always will be blank or get some default values if a projectmanager adds an existing tracker to his project. This prevents some information disclosure.
  2. Current existing trackers and their workflows will be reassigned to the existing projects and can be redefined after upgrade
  3. If a project is going to be deleted, their will be a check if the used tracker is reused in some other project. Otherwise it will be dropped with the project too.
  4. Workflow sets will always be dropped if a project is deleted
  5. Tracker and workflow creation would be managed with some permissions (this way old-fashioned administrator can restrict this and manage the trackers in the old way).
  6. The projectsettings (in administration) will get a new checkbox (flag), "Use own workflows". This flag defines if the projects allow own workflow and own tracker creation, if this flag isn't defined, the project will use the systemwide workflows with the trackers, which are assigned by the projectmanager.

This will help administrators, and give them the abbility to outsource some management to the corresponding projectmanager.

What do you think?

#27 Updated by Daniel Hochman almost 6 years ago

Not sure if this workaround was mentioned before, but you can create new roles for this purpose. For example, I have Role # 1 which I associate with specific statuses and workflow and only use Role # 1 in Project # 1. Then I have Role # 2 which I associate with other statuses and workflow and only use Role # 2 in Project # 2.

Not the cleanest but I think it works.

I also should mention that Admins will see all statuses regardless of roles.

#28 Updated by Lubos Racansky over 5 years ago

+1

#29 Updated by Toshi MARUYAMA over 5 years ago

  • Related to Feature #7839: Limit trackers for new issue to certain roles added

#30 Updated by Domingo Galdos over 5 years ago

+1

We could really use this. Our redmine instance is used by multiple stakeholders who want their own workflows, but as is they cannot manage them themselves, but must request it from the central administrator of the redmine instance, and even then care must be taken to avoid/resolve conflict.

#31 Updated by Toshi MARUYAMA about 5 years ago

  • Related to Feature #5991: Tracker should have it's own default issue status added

#32 Updated by Sergey Semenov about 4 years ago

+1 it is highly desirable feature for multy-project deployments.

#33 Updated by Vlad Vor about 4 years ago

+1 I need it every day!!!
Going to try this plugin https://github.com/jjrosalesuci/redmine_auto_assigned

#34 Updated by Leonid Byakov over 3 years ago

+100 Really!

#35 Updated by Joaz Soares over 3 years ago

+1

#36 Updated by Dmitry Ro over 3 years ago

+1

#37 Updated by Kirill Prokin over 3 years ago

+1

#38 Updated by budo kaiman over 3 years ago

+1

#39 Updated by Alexander Lapshin over 3 years ago

+1

#40 Updated by Inese Ez over 3 years ago

+1

#41 Updated by Gayathri Jayakumar about 3 years ago

+1 I would also require this kind of feature where workflow can be defined at a project level. Since we have project that follow different workflows and statuses

#42 Updated by Anh Le Giang almost 3 years ago

+ 1
I need different issue status for different project since we also have marketing and sales team using Redmine.

#43 Updated by Go MAEDA over 2 years ago

#44 Updated by ale dp over 2 years ago

+1

#45 Updated by Stephane Evr about 2 years ago

+1

#46 Updated by Frederico Camara about 2 years ago

Maybe this is related to Feature #20384, which I implemented at work. We have been using it for about a year:

I added an abstraction layer called Workspace so you could have different workflows. You then choose which workspace each project is using.

I added a patch there against Redmine 3.3-stable. It can potentially break some plugins, I have some fixed at github.com/fredsdc.

#47 Updated by Axel Ronsin about 1 year ago

+1

Any chance this will ever happen ?

#48 Updated by sebastien lemaitre 11 months ago

+1

Also available in: Atom PDF