Project

General

Profile

Actions

Feature #1853

open

Make Projects truly independent of each other

Added by Jim Jones about 16 years ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Projects
Start date:
2008-09-04
Due date:
% Done:

0%

Estimated time:
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 ProjectClosed2008-10-23

Actions
Related to Redmine - Feature #973: Assign different status sets and workflows for separate projectsNew2008-04-02

Actions
Related to Redmine - Feature #2905: Enable per-tracker issue status setClosed2009-03-05

Actions
Related to Redmine - Feature #850: Per-project role permissionsNew2008-03-14

Actions
Related to Redmine - Feature #552: Document categories on a per project basis and support sub categoriesNew

Actions
Related to Redmine - Feature #1086: Fine grained permissionsNew2008-04-22

Actions
Related to Redmine - Feature #3967: Ability to define default columns to display based on projectClosed2009-10-04

Actions
Related to Redmine - Feature #4015: Make app settings overridable at project levelNew2009-10-10

Actions
Related to Redmine - Feature #1767: Make spent time - & project custom fields configurable/switchable per projectNew2008-08-11

Actions
Related to Redmine - Feature #10027: Make "Required" overridable per-projectNew

Actions
Related to Redmine - Feature #5127: Custom Fields to be configurable on 'per project' basisNew2010-03-19

Actions
Related to Redmine - Feature #7349: Per-project email notification settingsNew2011-01-17

Actions
Related to Redmine - Feature #13742: Multi project for email incomingClosed

Actions
Related to Redmine - Feature #4462: Per Project Emission AddressNew2009-12-21

Actions
Related to Redmine - Feature #18424: can be in the project group managementNew

Actions
Has duplicate Redmine - Feature #18425: the custom fields can be defined in the projectClosed

Actions
Actions #1

Updated by Robert Chady about 16 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.

Actions #2

Updated by Marcus Beyer about 16 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.

Actions #3

Updated by Daniel Srb about 16 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.

Actions #4

Updated by Adam Soltys about 16 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.

Actions #5

Updated by Ewan Makepeace about 16 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).

Actions #6

Updated by Jim Jones about 16 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.

Actions #7

Updated by Muntek Singh almost 16 years ago

+1

Agreed! Goes along with issue #2076

Could really use this asap!

Thanks for a great system already though!

Actions #8

Updated by Jeffrey Hulten almost 16 years ago

+1

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

Actions #9

Updated by Zarooba Rozruba over 15 years ago

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

Actions #10

Updated by Jim Jones over 15 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.

Actions #11

Updated by Zarooba Rozruba over 15 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.

Actions #12

Updated by Zarooba Rozruba over 15 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.

Actions #13

Updated by Nikolay Kotlyarov almost 15 years ago

+1

Actions #14

Updated by Nikolay Kotlyarov almost 15 years ago

bounded with #559

Actions #15

Updated by Michael Ivanov almost 15 years ago

+1 I agree with previous speakers :-D

Actions #16

Updated by Emil Abdulnasyrov almost 15 years ago

+1

Actions #17

Updated by Richard Schulte almost 15 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.

Actions #18

Updated by Toshi MARUYAMA over 13 years ago

  • Category set to Projects
Actions #19

Updated by M Z over 13 years ago

+5 ;)

Actions #20

Updated by Etienne Massip over 13 years ago

  • Target version set to Unplanned backlogs
Actions #21

Updated by Etienne Massip over 13 years ago

  • Target version changed from Unplanned backlogs to Candidate for next major release
Actions #22

Updated by Robert Schneider over 13 years ago

+1

This would be a major forward step.

Actions #23

Updated by Mike Kokhanov over 13 years ago

+1

Actions #24

Updated by John Frey over 13 years ago

+1

Actions #25

Updated by John Frey about 13 years ago

+1

Actions #26

Updated by Steve Davis about 13 years ago

+1

Actions #27

Updated by Jost Mart about 13 years ago

+1

Actions #28

Updated by Dieter Egert about 13 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.

Actions #29

Updated by Neoscopio SA over 12 years ago

+1 Language settings per project is welcomed to!.

Actions #30

Updated by Dieter Egert over 12 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!

Actions #31

Updated by Simon Edwards over 12 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.

Actions #32

Updated by Michael Flyorko over 12 years ago

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

Actions #33

Updated by Juan Servera over 12 years ago

+1

Actions #34

Updated by Brad Rushworth over 12 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).

Actions #35

Updated by Hannes Meier about 12 years ago

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

Actions #36

Updated by yac yac about 12 years ago

+1
most importantly the Workflows

Actions #37

Updated by # And about 12 years ago

Neoscopio SA wrote:

+1 Language settings per project is welcomed to!.

+1
Really needed.

Actions #38

Updated by Glenn Gould about 12 years ago

+1
Important feature for us.

Actions #39

Updated by Markus Buchner almost 12 years ago

+1

Seperate Workflows and Custom Fields (especially Trackers!!)

Actions #40

Updated by Julien Purjuju almost 12 years ago

+1
Usefull feature!

Actions #41

Updated by Adrian Rotaru almost 12 years ago

+1

Actions #42

Updated by Anonymous over 11 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.

Actions #43

Updated by Mikołaj Milej almost 11 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).

Actions #44

Updated by Toshi MARUYAMA almost 11 years ago

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

Updated by Toshi MARUYAMA almost 11 years ago

Actions #46

Updated by Beni Bilme almost 11 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.

Actions #47

Updated by yac yac almost 11 years ago

Arbnor Qavolli Bilme Have you considered spinning up multiple instances of redmine for each department?

Actions #48

Updated by Miodrag Milic almost 11 years ago

+1, this is very important

Actions #49

Updated by Jérôme BATAILLE almost 11 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.

Actions #50

Updated by Jérôme BATAILLE almost 11 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.

Actions #51

Updated by Kostas Manios about 10 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!

Actions #52

Updated by Toshi MARUYAMA almost 10 years ago

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

Updated by Toshi MARUYAMA almost 10 years ago

  • Has duplicate Feature #18425: the custom fields can be defined in the project added
Actions #54

Updated by Publius Enigma almost 10 years ago

+1

Actions #55

Updated by Oleg Aksenov over 9 years ago

+1 - will be very useful

Actions #56

Updated by Omer Arslan over 9 years ago

+1 - will be very useful

Actions #57

Updated by Slawomir CALUCH over 9 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?

Actions #58

Updated by budo kaiman about 9 years ago

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

Actions #59

Updated by Florian ROBERT about 9 years ago

+1

Actions #60

Updated by Inese Ez almost 9 years ago

+1

Actions #61

Updated by Adnan Topçu almost 9 years ago

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

Actions #62

Updated by Zer Guz almost 8 years ago

+1

Actions #63

Updated by Rick Saccoccia over 7 years ago

+1

Actions #64

Updated by Go MAEDA about 7 years ago

  • Related to deleted (Feature #9194: Issues default list view layout configurable per project)
Actions #65

Updated by Edgars Batna over 6 years ago

+100500

Actions #66

Updated by Fabrizio Sebastiani almost 4 years ago

+1

Actions #67

Updated by thuruk thuruk almost 2 years ago

+1

Actions #68

Updated by Jérôme Gallot over 1 year ago

+1

Actions #69

Updated by mingming wang 5 months ago

+1

Actions

Also available in: Atom PDF