Feature #8979
open
Ability to activate a new member for a Project Leader
70%
Description
Hi !
In our company we use Redmine massively to manage our development projects.
We need to give the Project Leader a way to activate new users (only Administrators can do that for the moment).
- We can first suppose that the Project Leader has the Role :
Manage members : Allow user to add/remove project members or change the roles of existing members
So we don't need a new Role.
Among the collateral effects to take in account :If the Project Leader makes a mistake, he could validate people:
- that do not have to be in his project
- too soon
It's almost all, because the users could always be disabled or included in the right project to solve a previous mistake.
On this basis the feature consists in :
1) In the Project configuration page >> Members tab >> New member check-box list:
Add the users that are not yet enabled
2) In the controller that adds the members >> in the add member action:
Enable the user if it's not the case.
We are developing this feature by ourselves, is it interesting to propose a patch ?
Files
Related issues
Updated by Terence Mill over 13 years ago
related to "additive user managment for project managers" #8856
Updated by Jérôme BATAILLE over 13 years ago
We have developped the feature internally and are testing it.
- Members that are to be activated have their name greyed.
- After new members adding, a flash message lists the users that have been activated.
Updated by Terence Mill over 13 years ago
Would be interested to try it out if its a plugin. patching is no option for us.
Updated by Jérôme BATAILLE over 13 years ago
the feature is very small with very few board effects.
We do not plan to make a plugin, we hope our patch wil be accepted rapidly by the core developpers and included very soon.
Updated by Jérôme BATAILLE over 13 years ago
Updated by Jérôme BATAILLE over 13 years ago
Updated by Jérôme BATAILLE over 13 years ago
Terence Mill wrote:
Would be interested to try it out if its a plugin. patching is no option for us.
Are you talking as a Redmine user or as a core Redmine developper?
Updated by Etienne Massip over 13 years ago
- Assignee deleted (
Jean-Philippe Lang)
Updated by Jean-Baptiste Barth over 12 years ago
I don't think this kind of permission is needed in the core in that form, so you should implement it in a plugin (as suggested by Terence). I think it could only be added as a more general feature, such as "allow user management to non administrators".
Some general rules for this kind of contribution :- provide the patch in the same ticket (you can close the related patch you opened)
- patches can't be integrated without a complete test coverage (if it's a defect, tests should be "red" before the patches in app/ and lib/)
- patches can't be integrated if we cannot use them directly (in your case, this patch is full of comments that may be relevant for your company but not make sense in Redmine core)
- try to follow the same coding style as other sources in Redmine (no variables beginning with an underscore for instance)
I don't feel like closing the issue myself with my poor participation in the project on the last year, but some core developer might do...
Updated by Jérôme BATAILLE over 12 years ago
Hi Jean-Baptiste,
Thanks for your comments, I will take your remarks in account for the new patches we will provide.
Before some core developer close the issue, let me explain that this patch allows some flexibility that is very important in large companies.
All the project / users / issues management works well without administrator rights (we used to have more than 20 administrators and we now only need 2 or free).
The only day to day needs that we have and that require administrator rights is about users validation :
Customer users create their account themselves, and it's a little of a constraint to have an administrator to validate accounts (it's more than 10 users to validate by day).
The other interest of this enhancement is that two actions are merged : the project leader knows the customer well so he is the one that can validate an account and add him the right projects.
So my point is that in large companies this new way to validate accounts will spare exchanges and time by simplifying the user management process, without removing any interesting feature. Of course it could be disabled with a configuration option.
Updated by Jérôme BATAILLE almost 12 years ago
TODO :
- Patch to clean
- Tests to add
- Fix the filter of the list
Updated by Terence Mill almost 12 years ago
dupe: #8856
related to: New user management permissions: add own member, change role own member, delete own member
Feature #7980 extends this issue by only allowing to remove members which are added by role (project leader itself) also as rights which had been given by role itself. This restriction is represented by the word own in above issue topic name.
The intension is that by superuser( administrator or else) granted roles and rights can 't be changed by project leader.
Eg.g you wanna give and make sure that a group of people always has read/write acess or whatever rights on all or special projects by default. This is needed to enforce project wide rules that can't be disabled by project role memebers (e.g project leader role) by intent or ignorance of the system wide rules.
Another way to make that possible is to tag some roles as "project role", so that only this roles can be set or unset by any project leader. System wide roles (the other role category don't has to be explicit) then can be changed by this prohect admins, only by superuser role. This approach is more stable against project leader changes. Imagine a user has given a role to user in project and only this user can remove rights again (although admin) because this changes are bind to user. If this project leader leaves project nooone expect admin can ever revert.
The "project role" tag won't be bind to user but mark a role as generally (un)setable by non super users.