Redmine - Feature #973
Assign different status sets and workflows for separate projects
2008-04-02 05:14 - Clyde Goffe

ステータス:

New

開始日:

優先度:

Normal

期日:

担当者:
カテゴリ:

Issues workflow

2008-04-02

進捗率:0%

予定工数:

0.00時間対象バージョン:Resolution:
説明
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 setof statuses+workflows to their respective projects. This can be in addition to an already defined system wide setting that can beoverridden 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 theorganization 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
関連するチケット:
関連している Redmine - Feature #1853: Make Projects truly indep...

New

2008-09-04

関連している Redmine - Feature #3726: Trackers per Role

Closed2009-08-10

関連している Redmine - Feature #2905: Enable per-tracker issue ...

Closed2009-03-05

関連している Redmine - Feature #1966: Different set of Issue St...

Closed2008-09-29

関連している Redmine - Feature #2240: Ability to constrain trac...

Closed2008-11-27

関連している Redmine - Feature #285: Tracker role-based permiss...

Closed関連している Redmine - Feature #4828: Dynamic / modular workflows.

New

関連している Redmine - Feature #10331: Per-project 'Issue Close...

New

関連している Redmine - Feature #7839: Limit trackers for new is...

Closed2011-03-11

関連している Redmine - Feature #5991: Tracker should have it's ...

Closed2010-07-29

次のチケットが重複 Redmine - Feature #6436: Ticket Workflows as in...

Closed2010-09-20

次のチケットが重複 Redmine - Feature #10039: Issue statuses for ea...

Closed2010-02-13

履歴#1 - 2008-05-12 22:26 - Clyde Goffe
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 - 2008-08-15 21:14 - Mischa The Evil+1 :)#3 - 2008-08-16 00:20 - Thomas Pihl
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 nicesummary 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.

2024-09-09

1/6

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 - 2008-08-19 22:51 - Eric Davis
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 - 2008-08-19 23:35 - Clyde Goffe
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 - 2008-08-23 16:41 - Jim Jones+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 - 2008-09-03 15:54 - Brock Gunter-Smith+1Redmine should ideally allow setting master workflows and then override them at the project level if required.
#8 - 2008-12-03 05:00 - Harry Yamamoto
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 hugematrix 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.
/TYes,like workflow-name and status-name for grouping the workflows and statuses...
Hope the patch...
#9 - 2008-12-04 01:17 - Stephanie Collett+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 - 2009-02-28 00:58 - Enderson Maia
+1Thomas 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 - 2009-03-09 07:57 - Haomin Liu

2024-09-09

2/6

+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 - 2010-03-19 01:37 - Krzysztof Szalast+1
I also need that feature#13 - 2010-04-12 12:49 - Alexander Usikov+100
Actually we can't use redmine because of lack of this feature#14 - 2010-04-15 07:26 - Nikolay Kotlyarov+1#15 - 2010-06-09 13:41 - Raphael B+1#16 - 2010-06-10 00:45 - yannick quenec'hdu+1#17 - 2010-07-26 15:46 - Brent Shaffer+1. This would be such an amazing feature.
#18 - 2010-09-20 11:02 - goldleaf asd
SPAM#19 - 2010-09-20 11:03 - goldleaf asd
SPAM#20 - 2011-03-11 12:40 - Ryan Cross+1#21 - 2011-03-11 16:15 - Etienne Massip- カテゴリ を Issues workflow にセット
#22 - 2011-03-21 20:49 - ee se+1
#23 - 2012-03-06 16:01 - Overmind Eternal Will
+1
Also for my company this feature is blocking the adoption of Redmine for our workflow. :(#24 - 2012-11-12 10:33 - Patrick Feistel+1#25 - 2012-11-16 08:21 - Kenichi Handa+1#26 - 2013-01-12 17:47 - Daniel Felix
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 alreadyexists (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 upgrade2024-09-09

3/6

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 theproject 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 areassigned 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 - 2013-07-30 11:48 - Daniel Hochman
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 associatewith specific statuses and workflow and only use Role # 1 in Project # 1. Then I have Role # 2 which I associate with other statuses and workflowand 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 - 2013-10-01 11:44 - Lubos Racansky+1#29 - 2013-11-30 08:41 - Toshi MARUYAMA- 関連している Feature #7839: Limit trackers for new issue to certain roles を追加#30 - 2014-02-11 23:53 - Domingo Galdos+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 themthemselves, but must request it from the central administrator of the redmine instance, and even then care must be taken to avoid/resolve conflict.
#31 - 2014-03-06 05:28 - Toshi MARUYAMA- 関連している Feature #5991: Tracker should have it's own default issue status を追加#32 - 2015-04-27 16:34 - Sergey Semenov+1 it is highly desirable feature for multy-project deployments.
#33 - 2015-05-13 18:44 - Vlad Vor+1 I need it every day!!!
Going to try this plugin https://github.com/jjrosalesuci/redmine̲auto̲assigned#34 - 2015-09-11 11:11 - Leonid Byakov+100 Really!
#35 - 2015-09-18 19:31 - Joaz Soares+1#36 - 2015-09-24 11:13 - Dmitry Ro+1#37 - 2015-10-05 16:10 - Kirill Prokin+1#38 - 2015-10-05 17:08 - budo kaiman+1#39 - 2015-10-21 02:05 - Alexander Lapshin+12024-09-09

4/6

#40 - 2015-11-20 08:36 - Inese Ez+1#41 - 2016-03-30 11:09 - Gayathri Jayakumar+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 - 2016-07-20 10:01 - Anh Le Giang+1
I need different issue status for different project since we also have marketing and sales team using Redmine.
#43 - 2016-09-04 05:01 - Go MAEDA- 次のチケットが重複 Feature #10039: Issue statuses for each project を追加#44 - 2016-11-02 15:40 - ale dp+1#45 - 2017-03-13 11:41 - Stephane Evr+1#46 - 2017-03-13 19:48 - Frederico Camara
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 - 2018-05-07 19:25 - Axel Ronsin+1
Any chance this will ever happen ?
#48 - 2018-06-27 15:17 - sebastien lemaitre+1#49 - 2019-07-01 13:28 - Bartlomiej Skwira
11 years later and this feature is still more than welcome. Any chance to actually have it implemented?
#50 - 2019-10-20 11:10 - Luis Blasco+1#51 - 2020-03-03 13:45 - Elymar Silva+1#52 - 2020-10-29 13:06 - Gianni Cavallotto+1
At least as a first feature it would be enough to select which statuses can be visible or not by projects.
The administrator would have to take care on his/her own to maintain workflows feasible at any time a project define its set of statuses and not all
combinations of hide and show might be possible. But at least...
#53 - 2021-06-10 09:49 - Jihyeon Gim+1#54 - 2022-11-02 12:20 - thuruk thuruk+1
I think it is a real weakness for redmine to not have workflows by project. This was also raised up but shot down in #35544.
Taking my own example here, I've got 2 trackers, Bug and Feature.
However I have a project where issues need 2 levels of approval, as well as other checks.
On the other hand, I have a project for an internal ERP where the workflow is basically just New -> In progress -> Done.

2024-09-09

5/6

The solution here is clearly not to create 2 different trackers, that would mean that expanding on this principle would lead to having trackers
specific to each project's needs.
The simplest solution as it stands would be to create specific roles per project instead of specific trackers. But we're still duplicating something perproject, so this is not a good solution.
I truly think this is preventing a lot of the potential use of Redmine at scale.
Thanks :)#55 - 2024-01-23 06:56 - Jet Yan+1#56 - 2024-05-21 11:44 - mingming wang
+12024-09-09

6/6