Enhanced non-guest license control
Problem to solve
Today, anyone with a role of Maintainer or Owner in any project can assign a user to their respective project with a role > Guest. In doing so, they consume one license. In contrast, only an Owner is allowed to manage users at a Group level - Maintainers are prohibited from doing so. Further, there is no method currently available to prohibit a Maintainer from changing a user's role to something > Guest. This means that, without intending to, a Maintainer action can push a Buyer above their license count, resulting in back-charges.
To help support customer's ability to manage their license consumption, it should be possible to restrict promoting roles to a level that consumes a license (i.e. greater than Guest) to a smaller group of users than Maintainers.
Intended users
Buyers will rely on this ability to help them manage their costs. System Administrators (or their IT counterparts) will use this ability to control who is able to promote users such that they consume a license.
Further details
This issue becomes even more critical when users authenticate vs LDAP (or other external system), Allow sign-up is enabled, and any Maintainer of any project (including projects in a user's namespace) can promote any user to Reporter or higher. At that point, it becomes virtually impossible to control license usage other than reactively.
Proposal
Add an option (e.g. under Admin | Settings | General in one of "Visibility and access control" or "Account and limit") that lets the System Administrator choose whether to allow Maintainers to assign someone with either no role or a highest role of Guest to a higher role (e.g. Allow maintainers to consume a new license) within their project(s).
If the above option is False (or unchecked), then a Maintainer can only assign a role > Guest to a user that already has a role > Guest but an Owner can still assign any role to any user. If the above option is True, then Maintainer has the same ability as an Owner with respect to user role assignment in their project, which is the current behavior.
To maintain backwards compatibility with current behavior, the default should be True.
This would only impact project level membership since group level membership is already restricted to Owner roles - it essentially allows the System Administrator to restrict license consumption to Owners only.
Permissions and Security
The ability to check/uncheck the new options should be restricted to System Administrators. As described above, it would change the permissions of Maintainers in their projects as it applies to granting roles within their project.
While one could, in theory, go through every user and try to assign them to your project in an attempt to find those with a permission > Guest, such an effort would first require knowing who every user is via clever use of the existing search mechanism. The knowledge gained could potentially be misused, but the ability to automatically promote a user's role provides the same ability with much less effort.
Documentation
This would impact the list of permissions as well as a section in the Administration guide.
Testing
By setting the default to match current behavior, breakage is minimized. Testing should include cases for promoting users when:
-
User is in the group containing the project and
- has a role > Guest
- does not have a role > Guest
-
User is not in the group containing the project and
- has a role > Guest in any other project/group
- does not have a role > Guest in any project/group
The above would apply when the new options is both True and False.
What does success look like, and how can we measure that?
Buyers are able to have a (relatively) small group of Owners manage their licenses by controlling users permissions at a Group level. Once a user consumes a license, Maintainers are able to add/remove them with the same ease as they have today. For those Buyers who have other mechanisms for accomplishing the above, the existing behavior is still supported and is, in fact, the default.
This should (hopefully) reduce issues around license consumption as the Buyer and their System Administrator will have an enhanced ability to control who is authorized to initially consume a license.
What is the type of buyer?
This only applies to those levels that do not count Guest towards the count of licensed users
Links / references
N/A