The permission system serves as an access-control mechanism.
When a scanner, a design, or a graphic is uploaded/added to the database, the owner is given an access level of 999.
They then can grant permission of the item to other users with up to their own level, or adjust the value of another user who has a level lower than the current user.
Other users can repeat the process, assigning the item to even more users with an access level less than or equal to their own.
Access levels are checked in two ways:
fixed thresholds to veify what a user can and can not docustomizable access levels within a config to verify whether a user can read/write to a specific fieldFixed access checks utilize these thesholds to veify whether a user can perform a certain action.
Config access checks are freely selectable, and don't have to be chosen within these boundaries. It is, however, recommended to do so, as this ensures a consistent and less error-prone experience when working with multiple configs.
Each level includes those below, e.g. a user with access level of 250 for a given design can edit, read, and assign it.
These levels come spans of 100 because it will be possible to define very granular access to designs, e.g.
Note again that this feature is not yet implemeneted, and subject to change.
It is, however, already possibled to enter these values with this system in mind.
The following checks are performed based on a user's permission level for the given resource, and are not customizable:
300Similar to scanners and media, a user will have a permission level for any given config. On top of performing the fixed access checks listed above, they can also be used to limit access to individual fields within the config, both to read and write to said field.
Technical background
A config is stored as a single, large json file. Each value, such as the background image of a given page, is stored as a nested key within the json, for instance:
configs.01.01 - homeInit.design.backgroundwill store the background image string
To control access to a given field, this field can be given a minimum read- and write access level, for instance
design.background:
will result in the background string field of all pages to only be visible for users with an access level equal to or greater than 150 (otherwise, it will appear as unreadable characters), and only users with an access level equal to or greater than 270 can edit this field.
Fields can also be addressed in a more general way, for instance, the key
design
will control the access for the entire design part of all pages. In this fashion, every arbitrary sub-path can be used to control the access to a field, groups of fields, or even whole pages.
Note
More refined paths take priority over general paths.
design.background: read:150
will take priority over
design: read:180
for the background-field, so the minimum read-permission would be150, not180.
Key-paths may end with an asterisk (*), meaning that all fields that will match the partial path up until the asterisk will use this role. For instance:
design.* would affect all design-properties of this page.
Similarly, if the key-path is just an asterisk (*), this rule will affect the entire config.
Note
Explicit paths take priority over wildcards. As a rule of thumb, the more specific and exact the path, the higher the priority of the rule.
Note
Wildcards are only supported at the end of a key-path, not at the beginning or in the middle.
In addition to setting rules for a config, each page can get individual rules that take priority over config-wide rules. This can be used to, for instance, allow general access to the background image field, but make it read-only for most users for a single page by raising its permission requirements for that page only