Feature - User Add not just available to "Admin" user (#2255)

For reasons i honestly cant explain we hardcoded the creation of users to the user “admin” , this is there since the beginning.

Having access lists (and you being able to choose if a group has access to those buttons or not) we honestly see no reason why that should be there , is literally 3 lines of code. We’ll review the issue and if we find no reason why is there we’ll remove it.

The fix requires a few changes - today the situation is:

1- Today only admin can manage users under system / settings / users , we want to open this to any user that has the right visualisation and ACL permissions.

Visualisation Changes
We need to enable visualisations so not just admin can see other accounts ONLY if excepted on system / settings / visualisations. Admin will have still the hardcoded exception meaning always will see other accounts no matter what is defined on the visualisations exceptions. So if user X which belongs to any group is excepted on visualisations will see other accounts.

ACL

There are four key actions on ACL that control users:

  • /users/add
  • /users/edit (which edits accounts and also allows users)
  • /users/delete
  • importTool/upload/User (imports)
  • user comments and attachments

We need to create a group called “User Management” with description “This group allows members to add, edit, import and delete user accounts. Add this group to System / Settings / Visualisations / User Management if you want them to be able to edit and delete accounts other than theirs” that grants the permissions mentioned above.

Any user granted these permissions should be able to perform them, of course this is for nothing unless they are exempted on the visualisation settings mentioned above. Hardcoded conditions:

  • Admin can do all no matter what ACL is on it (this is default anyway)
  • Users cant delete their own accounts, the option should simply be not visible to them…now you see the delete option and get this error:

  • Users can not edit their own accounts, all fields (except password) are disabled:

I see no reason for this, if they have been granted edit permissions they should be able to edit all fields, so dont disable them.

5- the profile functionality (users/profile/) works even if its denied on the ACL (there seems to be an acl for this? which one?), that is fine as any user should be able to update their own password. i dont think the profile should allow users to modify the name, surname and email tough so please grey those fields out so they are not editable.

github: https://github.com/eramba/eramba_v2/issues/2255

We have groups that could use this functionality. Obviously I’m the one that ask for it but in our use case we have parts of our Risk Team that we do not want to make Admin’s But we want them to be able to make users so they can add users to send new Online Questionnaires to.

yes - this is on short term with prio-1 , so as soon as we get time it will be done!

Should be obvious, but please make sure users can’t add themselves to the Admin group =)

if a user has the power to create or edit (edit is different from changing its own password, this are separate actions) existing accounts, then the user will be able to give himself any role he wants!

I thought the point of this request was to allow users more control over accounts, without having to make them admins. If they can assign themselves the Admin role, that’s a pretty big flaw.

We dont know any system that allows an administrator (whatever group they have) grant user management privileges (create new accounts, edit, delete, etc) to other users under the limitation only certain groups can be assigned to users. Zendesk, Github, Aws, etc do not have such functionality either in our view…but perhaps we are understanding you wrong :slight_smile: