Old model using TavernAccess allows for decoupled model of access definition and access resolution. This makes it possible to define conflicting/nonsensical privileges, like:
Table is public and user has "access allowed"
Table is assistant admin and has access denied
Those don't make sense for access resolution point of view, but may make sense for user, i.e. accidentally making table public or private should not necessarily clear all fields for access allowed/denied fields before user changes their mind.
In the current/new model, this option is not well defined.
Decide what to do about it.
Options:
Use TableAccess as "user input definition", but resolve it on save into TableVisitor and always use that as normative access definition
Redefine sprava/pristup to be able to do both bitwise operations as well as independently store conflicting values
Remove the feature: if conflicting privileges are entered, refuse to save until immediately resolved by the user
Old model using
TavernAccessallows for decoupled model of access definition and access resolution. This makes it possible to define conflicting/nonsensical privileges, like:Those don't make sense for access resolution point of view, but may make sense for user, i.e. accidentally making table public or private should not necessarily clear all fields for access allowed/denied fields before user changes their mind.
In the current/new model, this option is not well defined.
Decide what to do about it.
Options:
TableAccessas "user input definition", but resolve it on save intoTableVisitorand always use that as normative access definitionsprava/pristupto be able to do both bitwise operations as well as independently store conflicting values