Separate group ranks into internal and external roles

[EchoReaper]

Continuing the discussion from Allow for two people to be in the ownership rank of my group:

tl;dr : Multiple group owner feature requests are not meant to emulate the broken behavior of the current bug

In-depth explanation

We’ve had multiple feature requests for groups to be able to have multiple leaders in addition to @sk3let0n’s thread that this branched from (e.g. @Sharksie made a feature request here, @Patrickblox here, etc) People, as evident by these three threads, seem to always jump to the conclusion that what was being requested would be bad behavior because if you had multiple leaders, how would group permissions work then? How would you kick another leader out if they’re also the leader? I’m guessing this concern is brought up by the broken behavior of the current bug which allows groups to have multiple owners in which you can’t exile the other group owners, but that is a bug, and not something we should model a feature’s behavior after.

tl;dr : Multiple group owner feature requests are posted for appearance – not permissions

In-depth explanation

The desire for multiple group owners comes not from the permission that rank entails, but instead the appearance of the rank. If the problem were that the non-owner wasn't able to change the description or use group payouts, a feature request for non-owners to be able to use those permissions would have been posted -- not a feature request for multiple group owners. Multiple group owners may be desirable where you have multiple founders for a group, who all contributed equally. You want all of those people to be looked at as a leader and not the individual designated as the logical group leader for administrative purposes.

@Gusmanak mentioned here that multiple group owners is a really niche thing and that it doesn’t have many uses cases, but luckily that fits in as part of a feature that’s much more usable by a much larger audience. Groups also happen to fall short in that the permission system is pretty weak, and like multiple group owners, that’s something that can do with some improvement.

tl;dr : ROBLOX hiding ranks from the group page and then us making ranks for each individual doesn’t cut it

In-depth explanation

Gusmanak suggests here that you just create a new rank for each person you want to assign individual permissions to, which wouldn’t be so bad once ranks weren’t publicly shown in the dropdown anymore, but I disagree. That just further complicates the current mess. Instead of breaking down the problem into something more manageable, you could be potentially creating hundreds of new ranks for individuals in a large group, which you may then forget what they entail. “EchoReaper’s Personal Role” doesn’t tell me much. Maybe I forget EchoReaper can shout in the group in that personal rank, but months down the road I don’t want him to be able to. It won’t be very apparent he has that ability.

The solution?

The separation of internal and external group roles. The external roles/ranks would be what you visibly see someone as on their profile or through :GetRank/RoleInGroupAsync() – essentially how ranks work right now. You’d still see people as “Private Blockhead” in any given group. However, in addition to these external roles, there should be internal roles. I could create as many internal roles as I wanted, and then assign any individual however many internal ranks I needed to. Internal ranks would overwrite the permissions of the external rank. (To resolve internal rank permission conflicts, the one with the highest 0-255 would take precedence).

Use cases:

• Create “Timeout” internal rank in which I can mute people by removing their wall-posting privileges without actually demoting them to the lowest rank
• Create “CanExile” internal rank to assign to my most trusted friends. Groups typically create a special rank for these people named “Vice Commander” or whatever, but this can lead to the people in that rank getting full of themselves, leading group leaders such as @imnotaguestimagirl to prefer keeping them in the same rank with other high ranks.
• Create “Community manager” internal rank which allows people who normally don’t have the permission to delete wall posts to delete them. Would be assigned to trustworthy, active people who couldn’t be promoted to a higher rank either because it was a game group and the next highest rank was “Developer” or it was a war group and they hadn’t earned a higher rank yet
• Create “DptHead” internal rank which contains the permission to shout which I could assign to people in charge of “departments” in groups. They may not be a high enough rank to shout and I may not be able to promote them for the same reasons in the previous use case, but still want them to be able to shout
• Create internal rank which allows people to create/edit group assets/games for people who normally don’t have that permission external rank-wise (mostly useful in war groups so they don’t have to create a “Developer” rank and those people can still partake in ranking up in the group normally)

How does this tie in with multiple group leaders? If internal and external permissions were separated, ROBLOX could then keep track of the true owner of the group with a ROBLOX-internal internal role, allowing that person to add and remove others to the owner rank, making it look like the group had multiple owners, but in actuality it didn’t. “Fake” group owners would not have the ability to use group payouts or change the description/logo since they weren’t the true owner.

[Lilly_S]

I think that we should definitely be able to assign permissions on a per-user basis in addition to a per-rank basis - meaning all Colonels can change ranks but only Colonel SampleUser can exile users.

[EchoReaper]

Yep – you’d be able to do that with internal roles. You could create an internal role called “ExilePermissionWhitelist” and assign it to Colonel SampleUser. My worry about individual permissions that are truly individual (i.e. you don’t create an internal permission and instead toggle the exile checkbox just for that user) is that it’ll be easy to lose track of who has special permissions and be difficult to manage them. For instance, let’s create an example group with the following permissions:

Leader - All permissions
HR - can shout, demote, delete posts, and advertise
MinimumRankToHostTraining - can shout, delete posts, and advertise
MediumRankishRank - can advertise
LowRankishRank - none other than the basics (post on wall and view wall/shout)

Now, suppose someone who’s rank MediumRankishRank becomes the department head. You individually set his permissions so that he can shout. Later, he’s promoted to MinimumRankToHostTraining, and a little after that someone else is elected department head and he needs to have any department head permissions removed. You have to first check this person’s current rank, then compare their custom permissions with their rank’s default permissions, and then modify their custom permissions so that they’re the same as the default. But alright, let’s say we do that. Now, let’s change things up a bit. This person was originally a MediumRankishRank similarly to last time, but prior to becoming department head he became a community moderator which he was given the ability to shout for. Same as last time he’s appointed to department head and then voted out later, and when you go to make his custom permissions the same as the MediumRankishRank default, oops! You removed the shouting permission! He’s a community moderator still and should have that privilege.

To be honest, I can’t take credit for that example – it isn’t original. The original context was regarding file/folder read/write permissions, and it’s something my class was taught in IT Networking when we were learning about Windows permission groups. For the very reasons mentioned above, Windows has permission groups (by default SYSTEM and Administrators), and any large network of computers will make use of a plethora of custom permission groups to avoid those kinds of problems from occurring. If we use internal roles on ROBLOX, we avoid that huge potential mess. When someone becomes a department head, you add the DepartmentHead internal role to them and they automatically get the appropriate permissions – you don’t have to toggle each on on individually. When someone loses their position as department head, you remove that internal role, and their permissions are what they should be – they automatically have the default permissions modified by whatever other roles they have (e.g. community moderator) , and you don’t have to manually compare their permissions with the rank’s default permissions. If implemented properly, you’ll also be able to sort members by internal roles, so you’ll be able to see all users with the Timeout role at a glance instead of having to manually upkeep a list of all the people who are on timeout.