Feature #9878
openNew permission to acces all informations of subprojects of a project
0%
Description
Hi, in my company we need a relay role for each Business Unit.
This role must have access to all sub-projects issues, wikis, documents, etc.
This responds to the need to have an account which can be used to have access to all the sub-projects informations of the Business Unit.
This is really useful in the case where the project leader and the project developers are not available, and the customer need to have a reply to a question related to the project (answer that often can be found in the Redmine tickets of the project).
The new permission for this role will be called See Sub-projects
ATTENTION: An user can only have once this new role. :
It's in the first role found that has this permission See Sub-projects that we get the project (the Business Unit) on which the member will have access to all the sub-projects.
The new permission has been translated in fr, en, es and uk(rainien).
We have developed an enhancement (that does not need much changes) and are testing it during next January. We will provide a patch as soon as the enhancement will be validated inside our company.
Related issues
Updated by Jérôme BATAILLE almost 13 years ago
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.
Updated by Jean-Baptiste Barth over 12 years ago
- 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.
Updated by Jérôme BATAILLE over 12 years ago
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.