FR: Sub-users/Instance based Role groups

[southnode]

This is not for requesting support for new games/applications

To do this you should go to https://github.com/CubeCoders/AMPTemplates and first attempt to build a configuration yourself - otherwise you can request a template from this repo.

Feature Request

Sub-users

Feature Information:

From a Gameserver point of view, most of the time it's not 1 person looking after it, it's multiple. From an auditing perspective each of these persons should have their own account.

Generally from an enterprise point of view, for the instance that a user rents, they should have control to be able to add, remove, and modify users within their instance, and set their permissions within the instance - I refer to these created users purely for those instances to be "Sub-users". I note that whilst you can create a user with the "Create User" permission, giving the other abilities as they currently stand would allow a user too much control in an enterprise setting.

From a configuration point of view, having another permission grouping under "Instance Management" where you have "Create User (This Instance), Modify User (This Instance), Delete User (This Instance), etc etc. Role Groups for the instance as well so that users may create roles (ie. Management, Administration, Moderator) with different permissions. This should be available to do for any user that has the "Manage" permission for the instance.

I confirm:

• [x] that I have searched for an existing feature request matching the description.

[PhonicUK]

AMP already allows for this? It's why a user cannot assign permissions that they themselves do not have.

[PhonicUK]

Some changes have been made to the permissions system to make this behave better. Users cannot assign roles to other users if the user making the change does not have all of the permissions within that role - so there's no longer a route for permission escalation.

[southnode]

Testing methodology before closing out this issue:

Create a test user - give minimal permissions Login as test user Attempt to create other user with permissions they can have and cant have

One caveat I think here is similar to #856 wherein there may be confusion when a user attempts to give a user a permission they themselves do not have - this may warrant another status symbol other than the tick or cross or grey which indicates a permission they cannot give. Things to think about @PhonicUK

[IceOfWraith]

This one is resolved as of a few months ago. The UI suggestion will be tracked under the referenced request.

[southnode]

@IceOfWraith this isn't resolved, and is one of our outstanding problems.

Users cannot create users - they don't show up Users cannot create groups - there is no option to do so within an instance Users cannot assign users to groups - there is no option to do so within an instance Users cannot assign permissions to users - there is no option to do so within an instance

[IceOfWraith]

I'll do a retest. Last I tried it worked fine creating users within an instance with a subuser.

[southnode]

Testing methodology @IceOfWraith for complete confidence in a controller > target setup in an enterprise environment:

Create a user, specifically have them have manage access to one instance Login as user into the instance Ensure that in the User Management screen, they can see nothing (as there are no local users - yet) Ensure that in the Group Management screen, they can see nothing (as there are no local groups - yet) Have the user create a new subuser - ensure that they can see the new user in User Management Have the user create a new group - ensure that they can see the new group in User Permissions Ensure that the user can only set group permissions that they themselves have access to (or better yet - they can only SEE the permissions they have access to) Have the user add their subuser to the newly created group via User Management screen Ensure that the user can change the subuser permissions on the User Management screen Check the subuser has correct permissions by logging in as the subuser, and can start/stop the instance as needed Ensure that the subuser cannot see anything they're not supposed to Ensure that the subuser, and group do NOT appear in the controller, and are not able to be selected in another instance Ensure that the subuser and group cannot login to the controller Ensure that the user can disable the subuser, and that the subuser no longer has access to the panel Ensure that when the user is disabled on the controller, that its sub-users are also disabled Ensure that when the instance is suspended, that users and subusers can no longer login to the instance Ensure the user can delete the subuser

[IceOfWraith]

This methodology is what I recall doing, but like I said I'll go through it again for sure.