PermissionsEx

PermissionsEx

14M Downloads

Add more attributes to configure how segments are stored

zml2008 opened this issue ยท 1 comments

commented

The base unit of permission storage is the segment. Currently segments are only split by contexts. Adding more segment-specific attributes would allow using segments to control other aspects of permissions resolution. However, a lot of the internal resolution of segments would have to become more complex.
Possible additional segment attributes:

  • Until (timed permissions implementation)
  • Inherit (whether or not values set in this context will be inherited -- could be a 'levels-of-inheritance' limit. This is similar to 1.x's prefixing permissions with # -- would have an inheritance limit of 1 when applied to groups). Otherwise a boolean.
  • Weight -- replace the key-value mapping of permissions used now.
  • Transient -- replace the separate MemoryDataStore? possibly? or just merge segments from the data stores -- so api-side they're the same implementation they're not.

To implement these changes, some more decisions have to be made, especially about how the commands interface for these changes would work.

  • How can users edit a segment with the current ingame model for setting permissions. Possible more long options would make sense here, which could then match against existing segment or create new one if options did not exist
  • Would it make sense to have these appear the same as contexts for users? Contexts could become properties of a segment rather than a separate subobjects, just remove the keys that have PEX-specific functionality? This would mean that some keys would become invalid for contexts (but this is the same as another plugin using those contexts if the keys are not stripped)
  • Can performance be maintained? We already cache results, so the this is not as critical as it would be if segment resolution had to occur on every permission check, but still very important.
  • Would it be possible to use the matches() method of all ContextCalculators for the contexts rather than using the current combinations system? Does it make sense to register ContextCalculators for specific contexts? Could this be an addition to the ContextCalculator interface?
commented

Related to #1577?