Redmine

There's an implicit implication of this feature, the role that as this new permission will have access to the sub-projects informations regarding the permissions of the role.
This means for example that if the role has only the view issues permission and not the modify issues permission, in all the sub-project he will only be able to see the issues.

• administrators can do and see (nearly) everything
• other users are stuck to the permissions inherited from the roles they have on each project

But even with this simple model, it can be hard to respect permissions everywhere, and it becomes a tiny nightmare when you develop plugins.

So either we add a permission like you suggest (but it would need a strong test suite to be sure we don't introduce unwanted behavior), either we add a rake task to propagate permissions of a user to sub-projects. Last but not least, you can decide managers are administrators of the instance, making your use case trivial to solve.

Let me know what you think.

Hi Jean-Baptiste,

Hi Jean-Baptiste Barth wrote:

It's a common problem for big Redmine instances I think.
So either we add a permission like you suggest (but it would need a strong test suite to be sure we don't introduce unwanted behavior),

I will provide a patch for this feature, but the changing are pretty simple. And it's possible to find all the places where we must apply it.
Thus the impact on the test suite is delimited.

either we add a rake task to propagate permissions of a user to sub-projects.

This can be a solution, but this would mean :
- effects not applied instantly
- additional load of the server

Last but not least, you can decide managers are administrators of the instance, making your use case trivial to solve.

It's not a solution that is acceptable in large companies, because it means that Business Unit managers could do stuffs in other Business Units, is hierarchically a problem.