Database - [Permission] structure

[tylerjwatson]

Rationale

TShock's permission system is made up of a comma-separated list of groups, using SQL only as a storage engine and not what it's supposed to be used for. Most of the performance problems with the AAA system can be resolved by using proper schema.

Structure

• [Permission] table:
  • ID - primary Key
  • Name - permission name
• [GroupHasPermission] joiner table:
  • PermissionID - Primary key
  • GroupID - Primary key
• [UserPermission] table:
  • UserFK - Foreign key to [User]
  • PermissionFK - Foreign key to [Permission]
  • IsNegated - Indicates whether a permission is to be explicitly negated

    Precedence rules

HasPermission follows these rules:

1. [User] has an explicit [Permission], and if IsNegated immediately returns the value of IsNegated
2. For each [Group] assigned to [User], if the [Group] has permission then immediately returns true, else it continues on to the next group
3. Finally, returns false if no groups contain the permission

   Notes

   • Plugins should have their own permissions which Orion shall iterate over, and insert into if necessary during Orion's init phase
   • [Permission] should be many-to-many with [Group] which in turn is many-to-many with [User](pending #8)
   • One [Group] may have many [Permissions], in turn, one [Permission] may have many [Groups]
   • May be cached on Orion's init system, though shouldn't impact too much SQL with proper indexing

[Ijwu]

Is many-to-many between [User] and [Group] necessary? Do we want users to be able to belong to multiple groups?

Edit: Ok, I missed #8. I can agree with @WhiteXZ's take. You can dismiss my comment.

[tylerjwatson]

Reopening this as it's valid in new orion