RFC: Better plot flag/user/group management

This brain dump has been brought to you by the numbers 1, 14 and 2, and the letter F (RIP my brain) And was requested by City. (YOU BRAIN MURDERER!!!)

PlotSquared Feature Suggestion:

From a user's perspective, the plot flags, user groups and permissions are a total, chaotic mess.
I have 2 suggestions to fixing them. The second depends on the first, more or less, and is to use either book or chest UI (or possibly even a lectern on the plot wall) to configure these settings. That can come later though. Re-organizing the command line stuff would be more beneficial in the near future.

How should it be implemented?

There needs to be a set of flags, users, groups and permissions options (herein "options") which are available only to the plot owner (owner). There then needs to be a permissionable set of options which the owner may assign to trusted, member, non-trusted, non-member, banned ("groups") At this point, we're talking about a full on plot-based permission system. This can be created one of two ways - either abusing per-player permissions (by adding "plots.plotperms....." to the non-owner guest player) or by storing similar data through some PlotSquared controlled storage means (plot database, etc)

Let's go over the permissions:
- This is used to specify that the permission is only applicable on plots owned by this player.
- the specific plot the perms are available on (both as a check and verify the correct plot is being used)
- can be plot, flags, groups, users, permissions - giving the following level of control over those options to the guest player

- add/set/remove etc, applying to each optiontype - 0, 1, 2, 3. 0 being "explicitly does not have" "has, and can use" "has, can apply towards users in lower groups" "has, can apply to all groups except owner"

Similarly, the player commands would follow this example, and would provide intelligent context.
/ps
(where parameters can be an item, group, permission, player, etc)

and a simplified admin commands:
/ps-admin

The exception would be /ps plot which only the owner and server admins (with permission) may run, affecting core plot functions - such as delete, clear, copy/paste/schematic (and it's sub-options), merge/unlink, move, and done <on|off>. (I may be missing a few)

Plot claiming should be done with /ps claim - thus allowing for /ps claim <buy|bid|sell|auction>
This would not rely on specific plot permissions, but would be permissionable through the servers' pms, allowing server admins to retain who can claim, buy, sell, etc

Certain other permissions would also have to be managed with the servers' pms, such as claim limits, ability to link/unlink, buy/sell/auction, delete, etc.

There should be a base set of permissions, which are inherently given to all players through the servers' pms. Adding these permissions will either do nothing (other than show the visibility of the permission for admins) or re-allow the permission in groups which inherit a negated form of the permission. These permissions should be broken down into basic, base, option, suboption and parameters.

basic:
/plotsquared (and it's aliases (/ps))
/plotsquared-admin (/ps-admin /psadmin)
plotsquared.commands.user
plotsquared.commands.admin

base:
/ps claim|plot|user|group
plotsquared.[claim|plot|user|group]
option:
/ps
plotsquared..[use|buy|bid|sell|auction]|[clear|move|copy|schem|,etc]|[add/set|remove|promote|demote|ban|mute|kick|,etc]|[add|remove|deny]
(The first applying to claim, second to plot, third to user-group assignments, fourth being group-permission assignment (i.e. what permissions does each group have?))

This will provide a more organized hierarchical approach to both server side permissions as well as plot group permissions, while retaining control for the admins. This would then allow for a cleaner display of the next available command parameter to the user, potentially with the ability for notating the purpose/use. Only options/parameters which the user is allowed will be visible.

When the user types /plot - they will be greeted with the popup options in the text bar, such as with mojang's commands. If they send the command alone, it will give them the help output for all acceptable/allowed options for "/plot" - and this would cascade down until they enter a proper command. Additionally, "help" can be appended between "/plot" and the option, providing the same context, with the addition of not sending a proper command, but instead showing what that command would do. Doing "/plot help claim" would show the player something along the lines of "This command will claim the plot you are standing in, if it is freely available to claim and if you have enough free plot claims" whilst doing "/plot [help] claim buy" would show something akin to "This command will purchase this plot from it's owner, provided you have enough free plot claims \n This plot is [not] for sale[: ]"

This concept should be able to be applied to all PS commands, as well as FAWE. Additionally, Plot flags could be used by the owner to specify if a group is allowed to use FAWE functions within the plot, provieded the needed links are built in between PS and FAWE; or if none are needed, then it may also work with WorldEdit as well.

Additional context

my brain hurts now. I'm sorry for the headache you've recieved from reading this. I know it sounds like how permissions/flags/groups/etc are currently handled, but I feel it's a bit more polished and may require more than just re-arrangement of command permissions in the plugin.yml.

Breaking the commands down into bite size chunks would more easily allow for the creation of an in-game UI that is both efficient and easy for the players to understand and use.

Checklist:

• I made sure there are no duplicates of my suggestion (Use search)
• I made sure my suggestion does not exist yet (Check the wiki)
• I made sure my suggestion is useful for the majority of PlotSquared users

Start by reviewing the current implementations of the /ps and /ps-admin command trees, plot flags, user groups, and permissions; the issue does not name specific files or tests. Before coding, narrow the proposal to a decided scope and define how command hierarchy, plot ownership, group inheritance, and server permissions should behave, then add coverage for the agreed behavior.