Permission system

Summary

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:

They are compared to fixed thresholds to veify what a user can and can not do
They are compared to customizable access levels within a config to verify whether a user can read/write to a specific field

Generel access levels

Fixed 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.

0-99: Assign this resource to an item (e.g. assign this config to a scanner)
100-199: Read this resource (e.g. open a config and view its contents)
200-299: Edit the resource
300-399: Assigned the resource
400+: Delete / Manage permissions of / Import / Export this resource

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.

200: Only edit the name of pages
210: Add the background image of a page
220: Add new elements
...

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.

Fixed access checks

The following checks are performed based on a user's permission level for the given resource, and are not customizable:

When assigning a resource (scanner, design, media) to another user, the own access level for this resource needs to be equal to or above 300

Config access checks

Similar 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.background will 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:

read: 150
write: 270

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 be 150, not 180.

Wildcards

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.

Page-specific rules