Redmine

+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.

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

+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.

+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.

-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).

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.

+1

Agreed! Goes along with issue #2076

Could really use this asap!

Thanks for a great system already though!

+1

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

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

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.

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.

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.

+1

bounded with #559

+1 I agree with previous speakers :-D

+1

+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.

+5 ;)

+1

This would be a major forward step.

+1

+1

+1

+1

+1

+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.

+1 Language settings per project is welcomed to!.

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!

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.

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

+1

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).

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

+1
most importantly the Workflows

Neoscopio SA wrote:

+1 Language settings per project is welcomed to!.

+1
Really needed.

+1
Important feature for us.

+1

Seperate Workflows and Custom Fields (especially Trackers!!)

+1
Usefull feature!

+1

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.

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).

+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.

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

+1, this is very important

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.

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.

• 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).

• 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.

+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!

+1

+1 - will be very useful

+1 - will be very useful

+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?

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

+1

+1

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

+1

+1

+100500

+1

+1

+1