Redmine

related to "additive user managment for project managers" #8856

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.

Would be interested to try it out if its a plugin. patching is no option for us.

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.

Patch added for Rails V1.2.1 #8979

Jérôme BATAILLE wrote:

Patch added for Rails V1.2.1 #8979

The patch is here #9041

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?

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

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

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.

TODO :
- Patch to clean
- Tests to add
- Fix the filter of the list

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.