Feature #1853

Make Projects truly independent of each other

Added by Jim Jones over 8 years ago. Updated 6 months ago.

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

0%

Category:Projects
Target version:Candidate for next major release
Resolution:

Description

Trackers, Issue Statuses, Workflow, Custom Fields and Enumerations should be configurable per project, not globally like it is now.


Related issues

Related to Redmine - Feature #2076: Individual Permissions for Each Project Closed 2008-10-23
Related to Redmine - Feature #973: Assign different status sets and workflows for separate p... New 2008-04-02
Related to Redmine - Feature #2905: Enable per-tracker issue status set Closed 2009-03-05
Related to Redmine - Feature #850: Per-project role permissions New 2008-03-14
Related to Redmine - Feature #552: Document categories on a per project basis and support su... New
Related to Redmine - Feature #1086: Fine grained permissions New 2008-04-22
Related to Redmine - Feature #3967: Ability to define default columns to display based on pro... Reopened 2009-10-04
Related to Redmine - Feature #4015: Make app settings overridable at project level New 2009-10-10
Related to Redmine - Feature #1767: Make spent time - & project custom fields configurable/sw... New 2008-08-11
Related to Redmine - Feature #9194: Issues default list view layout configurable per project New 2011-09-06
Related to Redmine - Feature #10027: Make "Required" overridable per-project New
Related to Redmine - Feature #5127: Custom Fields to be configurable on 'per project' basis New 2010-03-19
Related to Redmine - Feature #7349: Per-project email notification settings New 2011-01-17
Related to Redmine - Feature #13742: Multi project for email incoming New
Related to Redmine - Feature #4462: Per Project Emission Address New 2009-12-21
Related to Redmine - Feature #18424: can be in the project group management New
Duplicated by Redmine - Feature #18425: the custom fields can be defined in the project Closed

History

#1 Updated by Robert Chady over 8 years ago

+1 on this in a big way. I've kept quiet about this for now, but it definitely should have granularity down to the project level rather than global.

#2 Updated by Marcus Beyer over 8 years ago

+1 from me as well. The global configurations are one major problem that's keeping redmine from becoming truly a mutli-project tool.

#3 Updated by Daniel Srb over 8 years ago

+1

Marcus: this is not the problem of being truly multiple project tool, but of being multiple teams/methods tool. If you were doing same kind of projects with a same methodology, this would be no problem.

We solve this problem by having more trackers, roles than would be needed in the case of really independent config.

If you don't mind their names, trackers are no problem, you can choose only those you need per project. And because of workflow you can eliminate not needed statuses by simply not including them in a workflow for extra role you create just because of that.

Not ideal, but works.

On the other hand, if I have to configure workflow for multiple roles for every started project, it would be tedious.

#4 Updated by Adam Soltys over 8 years ago

+1

I'm the redmine admin for a department of the Canadian federal government and we have multiple teams across the country using the same redmine installation for multiple projects (64 projects in redmine at last count!)

Being able to configure the projects separately would be very helpful. Right now we have done the same as Daniel in that we have more trackers, roles, statuses etc. than we need for any given project and we have to name everything like "Project Manager / Gestionnaire de Projet" to satisfy bilingual requirements.

Maybe you could introduce the idea of "Project Templates" that represent a particular configuration of settings. These templates could be re-used by multiple projects so that all the settings wouldn't necessarily need to be configured for each new project.

#5 Updated by Ewan Makepeace over 8 years ago

-1

I honestly believe that the current system gives the right mix of power and simplicity. It is easy to define a new tracker for a certain project and not use it for other projects, or a status for one tracker that is not part of the workflow of other trackers, but if you have some projects that differ from the rest of the projects so fundamentally that you need all new trackers and workflows then I think a new Redmine instance is the right approach rather than adding another layer of management to Redmine (and by extension every user).

#6 Updated by Jim Jones over 8 years ago

Ewan Makepeace wrote:

-1

I honestly believe that the current system gives the right mix of power and simplicity. It is easy to define a new tracker for a certain project and not use it for other projects, or a status for one tracker that is not part of the workflow of other trackers, but if you have some projects that differ from the rest of the projects so fundamentally that you need all new trackers and workflows then I think a new Redmine instance is the right approach rather than adding another layer of management to Redmine (and by extension every user).

I'm not sure what you mean by "another layer of management to every user"? This change would not add any complexity to the current way of managing projects. If you want all your projects to have identical properties then just clone an existing project.

Furthermore a separate instance of redmine for each project is not a workable solution at all, especially not for short-lived projects. Apart from the technical overhead you'd have to deal with n separate admin-interfaces and n different sets of user-accounts. The users will have to login n times to work on n projects. Features like "My Page" and any cross-project relations become essentially useless. It's a maintenance and usability nightmare.

Sorry, but if redmine wants to be a multi-project tool (which is the first bulletpoint on redmine.org, no less) then these issues must be addressed properly.
Until then at least my company will be forced to stick with MantisBT and JIRA because they can deliver where redmine can't.

#7 Updated by Muntek Singh over 8 years ago

+1

Agreed! Goes along with issue #2076

Could really use this asap!

Thanks for a great system already though!

#8 Updated by Jeffrey Hulten over 8 years ago

+1

Project level security control is key... Especially for the anonymous and non-member roles.

#9 Updated by Zarooba Rozruba about 8 years ago

How do you intend to track issues across projects? (I use sub projects to track independent repositories yet related modules).

#10 Updated by Jim Jones about 8 years ago

Zarooba Rozruba wrote:

How do you intend to track issues across projects? (I use sub projects to track independent repositories yet related modules).

I don't think it makes sense to have a single issue be part of multiple projects.
Instead I would create a new issue in project B and relate that to the issue in project A.

Example:

Project A is "Planning"
Project B is "Programming"

Issue #1 in A is: "Create a fancy website"
Issue #1 in B is: "Create graphics"
Issue #2 in B is: "Create code"

The issues in project B would be children of issue A.
Issue A should also reflect the aggregate status (percentage done) of the sub-issues.

#11 Updated by Zarooba Rozruba about 8 years ago

Jim Jones wrote:

Zarooba Rozruba wrote:

How do you intend to track issues across projects? (I use sub projects to track independent repositories yet related modules).

I don't think it makes sense to have a single issue be part of multiple projects.
Instead I would create a new issue in project B and relate that to the issue in project A.

Example:

Project A is "Planning"
Project B is "Programming"

Issue #1 in A is: "Create a fancy website"
Issue #1 in B is: "Create graphics"
Issue #2 in B is: "Create code"

The issues in project B would be children of issue A.
Issue A should also reflect the aggregate status (percentage done) of the sub-issues.

And how would you reflect that issue #1 in B refers to Issue #1 in A?
Currently, there is no duplicate issue number across any of the projects.

Assume in your scenario someone asks ''whats with issue #1'', what would be your answer? Depends on project?

I am asking, that even if things get separated, issue numbers are never duplicated between projects.

#12 Updated by Zarooba Rozruba about 8 years ago

Adam Soltys wrote:

+1

I'm the redmine admin for a department of the Canadian federal government and we have multiple teams across the country using the same redmine installation for multiple projects (64 projects in redmine at last count!)

Being able to configure the projects separately would be very helpful. Right now we have done the same as Daniel in that we have more trackers, roles, statuses etc. than we need for any given project and we have to name everything like "Project Manager / Gestionnaire de Projet" to satisfy bilingual requirements.

Maybe you could introduce the idea of "Project Templates" that represent a particular configuration of settings. These templates could be re-used by multiple projects so that all the settings wouldn't necessarily need to be configured for each new project.

I would ask, can translations also be applied to things like :
- Statuses / Trackers / Roles ?

I am in similar situation. 200 projects across couple provinces.

#13 Updated by Nikolay Kotlyarov over 7 years ago

+1

#14 Updated by Nikolay Kotlyarov over 7 years ago

bounded with #559

#15 Updated by Michael Ivanov over 7 years ago

+1 I agree with previous speakers :-D

#16 Updated by Emil Abdulnasyrov over 7 years ago

+1

#17 Updated by Richard Schulte over 7 years ago

+1

It would be nice to be able to choose whether a project would be independent at creation, or what features would be independent at least. thus with simpler projects you could inherit site-wide settings, and for more complex and highly tailored projects you can fine tune.

#18 Updated by Toshi MARUYAMA about 6 years ago

  • Category set to Projects

#19 Updated by M Z about 6 years ago

+5 ;)

#20 Updated by Etienne Massip about 6 years ago

  • Target version set to Unplanned

#21 Updated by Etienne Massip about 6 years ago

  • Target version changed from Unplanned to Candidate for next major release

#22 Updated by Robert Schneider about 6 years ago

+1

This would be a major forward step.

#23 Updated by Mike Kokhanov about 6 years ago

+1

#24 Updated by John Frey almost 6 years ago

+1

#25 Updated by John Frey almost 6 years ago

+1

#26 Updated by Steve Davis over 5 years ago

+1

#27 Updated by Jost Mart over 5 years ago

+1

#28 Updated by Dieter Egert over 5 years ago

+1

Also the language needs to be defined per project, as members of a project will communicate with that language and will need same theme (names of redmine features) to discuss about.

#29 Updated by Neoscopio SA over 5 years ago

+1 Language settings per project is welcomed to!.

#30 Updated by Dieter Egert about 5 years ago

Please don't forget to introduce separate folders for attachments / files per project, and issueIDs to be valid (unique) only together with the projectID.

With that it will be possible to export / import projects to different redmine installations!

#31 Updated by Simon Edwards about 5 years ago

Dieter Egert wrote:

Please don't forget to introduce separate folders for attachments / files per project, and issueIDs to be valid (unique) only together with the projectID.

I think this would be a quite fundamental change in the way Redmine works - the fact that issues can be moved between projects and are uniquely identifiable without a project ID is important for anyone whose workflow involves moving issues between different projects. The same therefore goes for items attached to issues too.

#32 Updated by Michael Flyorko about 5 years ago

+1
very helpful for multi-project-manager/multi-project-type/multi-customer companies. Especially in service outsourcing.

#33 Updated by Juan Servera about 5 years ago

+1

#34 Updated by Brad Rushworth about 5 years ago

I'm the administrator of HostedRedmine.com, a free community service.

The addition of this feature #1853 would make a big difference to the type of service I could offer the public (at no charge). Our users don't have access to the Administrator settings, so they cannot currently customise Trackers, Issue Statuses, Workflow, Custom Fields and Enumerations.

I'm curious as to how http://m.redmine.org/hostings/new works. Did someone customise Redmine to make this work? Have they implemented something like this feature request? Or do they simply create a new instance for each additional demo (seems unlikely).

#35 Updated by Hannes Meier almost 5 years ago

+1
especially using folders per project for files
at the moment file upload is really a mass, one folder for all projectfiles

#36 Updated by yac yac over 4 years ago

+1
most importantly the Workflows

#37 Updated by # And over 4 years ago

Neoscopio SA wrote:

+1 Language settings per project is welcomed to!.

+1
Really needed.

#38 Updated by Glenn Gould over 4 years ago

+1
Important feature for us.

#39 Updated by Markus Buchner over 4 years ago

+1

Seperate Workflows and Custom Fields (especially Trackers!!)

#40 Updated by Julien Purjuju over 4 years ago

+1
Usefull feature!

#41 Updated by Adrian Rotaru over 4 years ago

+1

#42 Updated by Joshua DeClercq over 4 years ago

While I very much support this request, the more experience I get with Redmine, the more I think I'd recommend running multiple instances just to avoid some of Redmine's toughest challenges.

Upgrading Redmine is intimidating. In a corporate setting with hundreds of people relying on it, simply getting the ball rolling on an upgrade requires dozens of man hours of planning and testing. Separate Redmine servers (VMs are your friend) greatly simplify rolling out new versions of Redmine, and taking advantage of external auth services keeps user accounts consistent. Eliminating the need for migration when upgrading is a bigger deal than you might realize early on, and you get per-instance control over everything.

Letting yourself and your business get too deeply invested in a single Redmine instance will only cause risk to increase over time as valuable data stacks up in a single location. You also risk overwhelming users and administrators with complexity: configuring workflows across roles and trackers is already a daunting effort. Adding the potentially massive granularity of individual projects gives me sweats.

However, I like the idea of adding, say, a 'Custom Fields' tab to the Project Settings view, independent of the Administration version. If this is planned for implementation some day, my only request is to make this something that can be inherited. Add sharing similar to versions, allow for continued global configuration at the Admin level, and guard against duplicate names (if an 'Affected Version' field is created globally, prevent the same name being created per-project). With all that in mind, +1.

#43 Updated by Mikołaj Milej over 3 years ago

In my case we have a small university server, with only 1 GB of ram so multiple instances of readmine are just impossible because lack of memory (we have several services on that machine)

So +1 for truly independent projects but unfortunately it requires quite big database redesign to do it right.

The option with independent instances of redmine it should be possible to easy migrate projects between instances. unfortunately that case probably requires even more database redesign (e.g. issue numbers).

#44 Updated by Toshi MARUYAMA over 3 years ago

  • Related to deleted (Feature #6176: Email Notifications per project)

#45 Updated by Toshi MARUYAMA over 3 years ago

#46 Updated by Beni Bilme over 3 years ago

+1
We have tried to customize the redmine for a 60 people organization. There are people with different profession. We are using redmine to track tasks. However we had to create lots of different trackers and custom fields. We had to give several people admin rights since customization needs admin rights in their departments. We currently understand that redmine is not appropriate if the company has diverse needs and not cohesion in its functions. Designing trackers, related custom fields which have global affect is a big issue. If we can allow users to create per project custom fields or trackers it would be tremendous help.

#47 Updated by yac yac over 3 years ago

@Beni Bilme Have you considered spinning up multiple instances of redmine for each department?

#48 Updated by Miodrag Milic over 3 years ago

+1, this is very important

#49 Updated by Jérôme BATAILLE over 3 years ago

Zarooba Rozruba wrote:

I would ask, can translations also be applied to things like :
- Statuses / Trackers / Roles ?

The localizable Plugin does that in a good manner.

#50 Updated by Jérôme BATAILLE over 3 years ago

After more than two years of administration of Redmine in your company (1156 living projects in 2013), I think that the way Redmine is designed about Workflow, Roles, Permissions and custom fields is part of it's genes.

To me, the pros of Redmine centralized administration are :
  • The fact is that these configurations are only available to admins, enforces strongly the processes inside the company.
  • Redmine is very comfortable to people that administer and design the company processes (for example in our company it takes only one person to achieve this task, and far from full time).
The cons :
  • It implies of course less liberty to the project managers, but this can be more or less balanced by fine tuned processes.
  • If Redmine is used for multiple type of jobs / domains, it's more complicated to configure different processes. But it's possible, with multiple optional trackers / workflows (with less clarity of course).

Changing to by project configuration seems to me to be a radical change. Other ALM softwares do very well with this kind of configuration. But I seems to me that it's a very different way to manage processes.
In any case it will imply big changes in the configuration pages, and quite a long thinking about how to do them the Redmine way :-)

Giving the ability to fine-tune Redmine on the project level, should perhaps be associated to the possibility to control at which degree of magnitude projects can be tweaked.

#51 Updated by Kostas Manios over 2 years ago

+1 from me

For some companies deploying a separate installation of Redmine for each project is simply not an option, and where the possibility exists it is still not very efficient.

Currently we have to give permissions we do not want because we need to maintain a minimum common denominator across projects. Making root-level projects independent would be a saviour!

For me the "admin->settings->projects" tab is probably the most important one that should be defined per project, followed by some things in "admin->settings->generic" such as upload limits etc.

BTW: Thanks for a wonderful product!

#52 Updated by Toshi MARUYAMA over 2 years ago

  • Related to Feature #18424: can be in the project group management added

#53 Updated by Toshi MARUYAMA over 2 years ago

  • Duplicated by Feature #18425: the custom fields can be defined in the project added

#54 Updated by Publius Enigma over 2 years ago

+1

#55 Updated by Oleg Aksenov over 2 years ago

+1 - will be very useful

#56 Updated by Omer Arslan over 2 years ago

+1 - will be very useful

#57 Updated by Slawomir CALUCH about 2 years ago

+1 if we could have project blueprints:

Each blueprint would allows a different configuration (trackers, permissions...)
When a blueprint is edited all projects with the current blueprint have their configuration changed This way there is still the option of keeping a global configuration for a given project type of for a given team.
The current server configuration could be migrated to a default blueprint.

Any thoughts on that?

#58 Updated by budo kaiman almost 2 years ago

+1 as it can become quite cluttered trying to manage multiple projects with different workflows.

#59 Updated by Florian ROBERT over 1 year ago

+1

#60 Updated by Inese Ez over 1 year ago

+1

#61 Updated by Adnan Topçu over 1 year ago

+1 You must think all system if you want to do minor improvement on a project. It's very tiring.

#62 Updated by Zer Guz 6 months ago

+1

Also available in: Atom PDF