Feature Request: Groups management

[mechite]

This is related to #326.
This proposes adding server groups + user groups.

Server groups may look something like the below example:

User groups are said by @DaneEveritt here to be:

So would teams be similar to organizations on Github

The original requester also asked for node grouping.
This was not discussed thoroughly.

[DaneEveritt]

There is a lot going on in that issue — I think it is kind of hitting on two distinct feature requests that might be better to break out here. It seems like there is a partial request for just basic grouping of servers in the UI for organizational purposes.

There is also the main request I'm seeing there which is something akin to GitHub organizations, or just "Teams" where a user can own or belong to multiple teams, and they have permissions assigned at a team level that apply to every server within that team.

I guess my question from there is two-fold:

1. A server not associated with a team would allow subuser assignment that only applies to it?
2. A server associated with a team would inherit user access and permissions from the team. Do we also need to support per-server subusers in those cases too? I'm guessing yes, where you can belong to a team with read access to all servers, and then maybe one specific server you're assigned directly to with additional write access?

Are there more things we need to consider here? Is this being over-complicated, or not accounting for other user cases? We should make sure to lay out all of the cases we're thinking of here because this is not a trivial addition, and going back to the drawing board once it is started because we forgot cases would be nightmareish.

Something tells me just building it similarly to how GitHub orgs work (where you can be an org member but have higher permissions on individual repos) would be the easiest way to design this?

[mechite]

Something tells me just building it similarly to how GitHub orgs work

I second that idea.

I think that a server not associated with a team is always associated with an "owner user".
That user could then set their own account permissions, and be the "org" holding that server, by default:

DaneEveritt { ... allow read access to User01, User02 }
|> minecraft-001 { ... allow write access to User02 }

Infraly { ... allow read access to User01, User02, sudo to User03 }
|> minecraft-002
|> minecraft-003 { ... allow write access to User02 }
|> minecraft-004

...so orgs are just like users.
Like GitHub, all "sudo" users on an org treated the same.
The user who creates an org is assigned "sudo" by default, but once they grant it to someone else, both of them just have joint ownership and could even remove each-other.

• Then you would just need the ability for a user, from the client area, to:

  • create orgs

  ---

  • manage permissions of orgs (affecting all org servers at once)
  • manage permissions of their account (affecting all of their servers at once)

  ---

  • manage permissions of their own servers individually
  • manage permissions of org servers individually

  ---

  • transfer servers between org (if you are "sudo" of the org), and yourself (your personal user)

---

It seems like there is a partial request for just basic grouping of servers in the UI for organizational purposes

This could just be a string "tag" property of the individual servers.
I don't think any more than that is necessary.
It could even be a syntax of the display name, e.g. {Minecraft}Lobby

[spencermacca]

There is a lot going on in that issue — I think it is kind of hitting on two distinct feature requests that might be better to break out here. It seems like there is a partial request for just basic grouping of servers in the UI for organizational purposes.

There is also the main request I'm seeing there which is something akin to GitHub organizations, or just "Teams" where a user can own or belong to multiple teams, and they have permissions assigned at a team level that apply to every server within that team.

I guess my question from there is two-fold:

1. A server not associated with a team would allow subuser assignment that only applies to it?

2. A server associated with a team would inherit user access and permissions from the team. Do we also need to support per-server subusers in those cases too? I'm guessing yes, where you can belong to a team with read access to all servers, and then maybe one specific server you're assigned directly to with additional write access?

Are there more things we need to consider here? Is this being over-complicated, or not accounting for other user cases? We should make sure to lay out all of the cases we're thinking of here because this is not a trivial addition, and going back to the drawing board once it is started because we forgot cases would be nightmareish.

Something tells me just building it similarly to how GitHub orgs work (where you can be an org member but have higher permissions on individual repos) would be the easiest way to design this?

I know that many use Pterodactyl to run their server hosting businesses, but putting that aside and focusing on who I believe this feature benefits the most, which is people running multi-server game networks (ie. Velocity), this really helps to clean up the server list and get work done easier in the panel

I think this would best be implemented via have some form of organise button on the homepage where you can sort and manage your servers into different categories with different colours. This only applies to you however an option could be enabled deeper in the admin settings to sync these changes for all who have access to the server(s) in question

As for also combining it with some form of permissions, so certain teams can access seperate categories, is a cool idea, though I can only see it making this more unnecessarily complex for the end user, I think managing access to servers should stay the way it is