ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Forums » Develop »

Project Specific Issue Status

Added by Romano Licker at 2011-06-01 04:44 pm

Dear ChiliProject-Community,

my name is Romano and I'm a developer at Finn-labs in Berlin.

We would like to extend the idea of issue statuses in the context of a project, meaning:
The setting is_closed (for a status) is configurable for each project.

The issue status "Pending" in project A results in a closed issue, whereas in project B "Pending" the issue is still open.

To write a monkey patch for this extension makes no sense since the changes would be to intense.

What we would like to change:

- remove the field "is_closed" (or even all customizable fields like is_default, default_done_ratio, etc.) from issue_statuses
- create a new table project issue status which references the issue_status and the project specific options(project_id, issue_status_id, is_closed, ..etc.)
- remove the view Issue Statuses from the administration-section
- create a new view in the administration/settings section, where you can define which options are default for new projects

Up to this point, this would basically replace the old behavior. New projects would have these 'global' (default) settings and only if the user wants to, he could change the settings for a project -->
- add a tab in the project/settings section, where you can change the is_closed, etc. parameters

What is your opinion about the change and the implementation?

Kind Regards,

Romano


Replies (1)

RE: Project Specific Issue Status - Added by Eric Davis at 2011-06-03 03:43 pm

Romano:

tl;dr: I like the idea of project specific issue statuses but think there is a better way to approach this.

I don't really like this idea. The good thing about issue statuses was that they were consistent across project to project. Making them project specific would make things even more complex when you think about the Tracker <=> Workflow <=> Issue Status.

If what you are wanting to do is to provide a way for Projects to override fields like is_default, I'd approach it the same way Time Entry Activities work now. They are set up so you have a system-wide version but on a project you can override them to change custom fields. Example with a bit of data:

  • Development - systemwide, project_id = nil, custom_field_a = "foo"
  • Development - on ProjectX, project_id = 5, custom_field_a = "bar"

If you do issue statuses this way:

  1. the default systemwide versions would still work as before
  2. the project specific ones would override data as needed
  3. with a few accessor changes, the override could be transparent to other code. e.g. project.issue_statuses would return both system and project issue statuses
  4. not much would have to change for the workflow, project specific statuses would just need to find their related system status and then use that statuses workflow

That said; there are a few limitations with how project specific Time Entry Activities are implemented, mostly in the UI. They are set up so you can't easily override one activity and there is a lot of code to check if they are overridden. If per-project overrides are common to other data (like issue statuses) then we could see about improving them across the entire system.

Eric Davis

(1-1/1)