Patch #20384

Proposal: Workflow enhancement

Added by Frederico Camara over 1 year ago. Updated 10 days ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues workflow
Target version:-

Description

I work at a large ICT public company in Brazil and we are using Redmine here.

At first it didn't become apparent that the workflow tools in Redmine would be limiting in any way. But as we start to build more complex workflows and reutilize roles and tracker names for different projects and teams, we noticed that a workflow being inherent to a specific role and tracker, was making us come with similar names and synonyms to roles and trackers so we could develop new workflows for a different areas in our company. Examples of this are: using lower and uppercase in names, adding numbers, using words in both genders (substantives in portuguese have gender inflexion). Ultimately it became an annoyance, as similar entries would populate various menus across Redmine.

Also, the closed state being inherent to a issue status, also made we duplicate entries, bacause in a workflow, some state would close the issue whereas in another workflow, the same state would not.

I still think workflows should still be inherent to roles and trackers, but projects could have diferent workflow sets to choose from, so that you could still have different projects using the same workflow and at the same time could have different projects using different workflows.

Also, the closed state should be inherent to the workflow being used.

For a first proposal, I would have another entry in the admin menu for a workspace, workflow set, or workflow space, or whatever the best term is in english. From there, workflows would be part of a workspace and in each project you would select the workspace to use. For migration purposes, all existing and new workflows and projects would be assigned to the default workspace. New subprojects should have selected the same workspace as the parent at creation. There is no inheritance of workspace between projects.

The main advantages are:

  • fewer roles created;
  • fewer issue statuses created;
  • simpler migration between workflows;
  • more control over complex infrastructure;
  • very low impact on simpler infrastructure.

workspaces.patch Magnifier (51.9 KB) Frederico Camara, 2017-03-13 19:20

History

#1 Updated by Frederico Camara about 1 year ago

Implemented it as 'Workspaces', (except for the closed state) on my git repository with a few improvements, and it is awesome!

Now I can have different workflows assigned to the same tracker and role names, in different projects.

  • In Administration, you can add workspaces in 'Workspaces'.
  • In Administration > Workflow, there is a new filter 'Workspace'.
  • Changing the workspace switches between different sets of workflows (also working if the Field Permission tabs).
  • Summary has a dropdown menu to switch between different workspaces.
  • On Project > Settings, you can change the workspace the project is using.
  • You can't delete the default workspace (also, when migrating, this is where all previous workflows go to).
  • Patched against Redmine 3.2 stable.

How to get it:

git clone -b "3.2-patched" https://github.com/fredsdc/redmine <target directory name>

#2 Updated by Frederico Camara 11 days ago

I cherry-picked the commits and made the necessary ajustments against redmine 3.3 stable. Here's the patch.

It adds "Workspaces" in the Administration menu and migrates all existing workflows to the "default" Workspace.

For each project, you can select what workspace it will use. Workspaces separate workflows (transitions and permission) from each other so that different projects can have different workflows. It also tries to help administration.

This patch was made on Linux, for Windows you have to fix newline chars.

Changes:

  • In Administration, you can add workspaces in 'Workspaces'.
  • In Administration > Workflow, there is a new filter 'Workspace'.
    • Changing the workspace switches between different sets of workflows.
    • This is also working if the Field Permission tabs.
  • Administration > Workflow > Summary has a dropdown menu to switch between views from different workspaces.
  • Administration > Projects shows which workspace each project is using.
  • On each project > Settings, you can change the workspace the project is using.
    • On Information, Trackers are filtered by which trackers have workflow on the workspace
      • You can show/hide filtered trackers clicking on "all"
    • On Members, Roles are filtered by which roles have workflow on the workspace and those that can't have issues assigned to them (on Administration > Roles)
      • You can show/hide filtered roles clicking on "all"
  • You can't delete the default workspace (also, when migrating, this is where all previous workflows go to).

To patch (redmine 3.3-stable):

patch -p1 < workspaces.patch
bundle exec rake db:migrate
touch tmp/restart.txt

#3 Updated by Frederico Camara 11 days ago

Could someone change this Feature to Patch?

#4 Updated by Jan from Planio www.plan.io 11 days ago

  • Tracker changed from Feature to Patch

It's an interesting (albeit far-reaching and complex) patch, thank you for proposing it. In order for a patch of this magnitude to be considered though, it would need full test coverage and it shouldn't break any existing tests. If possible, I'd also recommend to break it down into a series of patches in which each patch results in a working version of Redmine with all tests passing, but separating your work into separate chunks that can stand by themselves.

From our work with Redmine in very large organisations at Planio the main requirement was for project teams to create their own trackers, statuses and workflows without the need of an admin and without interfering with other projects. Your patch seems to solve the latter challenge, but not the former one. With your solution, project teams requiring different workflows would still have to ask the Redmine Admin to create them for them, am I correct?

Especially in large organisations, this creates a real challenge because admins wear many hats and administer many different systems. They may not be 100% familiar with the configuration interfaces in the Admin area of Redmine and how they correspond to the business needs of a project manager requesting a certain workflow change. This creates potential for misunderstandings when project managers are requesting a different set of workflows via email or on the phone. Sitting down with the admin to create them is often hard to realize and can take weeks for a project to get their required workflows implemented.

I think that a solution where certain roles can manage trackers, statuses, and workflows for their projects individually would be a better suited solution to the challenge we've seen with many large organisations.

#5 Updated by Frederico Camara 10 days ago

Jan from Planio www.plan.io wrote:

It's an interesting (albeit far-reaching and complex) patch, thank you for proposing it. In order for a patch of this magnitude to be considered though, it would need full test coverage and it shouldn't break any existing tests. If possible, I'd also recommend to break it down into a series of patches in which each patch results in a working version of Redmine with all tests passing, but separating your work into separate chunks that can stand by themselves.

I should prepare a testing environment :-) The patch is the result of four commits on my github redmine tree, the main one changes about 30 files and is hard to break down, as soon as I add workflows to different workspaces, the test shoud break somewhere

From our work with Redmine in very large organisations at Planio the main requirement was for project teams to create their own trackers, statuses and workflows without the need of an admin and without interfering with other projects. Your patch seems to solve the latter challenge, but not the former one. With your solution, project teams requiring different workflows would still have to ask the Redmine Admin to create them for them, am I correct?

Yes, at least in this present state. We were already numbering roles and trackers to make different workflows, already not knowing which workflows were used in which projects, and querying the database. I started by trying to solve that problem.

Especially in large organisations, this creates a real challenge because admins wear many hats and administer many different systems. They may not be 100% familiar with the configuration interfaces in the Admin area of Redmine and how they correspond to the business needs of a project manager requesting a certain workflow change. This creates potential for misunderstandings when project managers are requesting a different set of workflows via email or on the phone. Sitting down with the admin to create them is often hard to realize and can take weeks for a project to get their required workflows implemented.

I think that a solution where certain roles can manage trackers, statuses, and workflows for their projects individually would be a better suited solution to the challenge we've seen with many large organisations.

You have to isolate these resources before empowering roles, or it could get out of control fast, for the Admins.

Workspaces could be extended to isolate Trackers, Issue statuses and Custom fields. You can extend roles so they could manage everything inside a Workspace. On top of that, the whole thing should be manageable by the admins, so the whole information has to be broken in manageable bits.

Also available in: Atom PDF