Tables in roles

All the database tables that you define are the subject of access rights held by roles:

Database Tables exist as physical database tables in the RDBMS. When you add or change authorisation on Database Tables, you may need to (re)run an Update Application Rights routine in USoft Authorizer in order to update database grants.

Subtype tables have their own access rights that are separate of the access rights on the supertype table. This is true independently of whether a subtype is implemented as a separate physical table in the database or not (something that you decide by setting or unsetting their "Create Separate Table" flag). If users are to be allowed full use of a subtype constellation, you must be careful to give them access rights both on the supertype and the subtype (or each of the subtypes).

These separate rights give you much flexibility, but also require that you to analyse each situation carefully. Just as an example, it makes no sense to give users INSERT rights on a subtype if they do not also have INSERT rights on mandatory columns of the supertype, since these are mandatory also for the subtype.

For a detailed discussion, go to Access rights for supertypes and subtypes.

The USoft authorisation system has separate access rights (Table Rights and Column Rights) for Logical Views and for their underlying table(s) (as well as for any underlying Logical Views).

But because of the special relationship between a Logical View and its underlying tables and views, these access rights are interdependent in practice:

•For foreground or background SELECT access to a Logical View, you need at least Background SELECT rights on underlying tables and views.

•For foreground or background INSERT access to a Logical View, you need at least Background INSERT rights on underlying tables and views.

•For foreground or background UPDATE access to a Logical View, you need at least Background UPDATE rights on underlying tables and views.

•For foreground or background DELETE access to a Logical View, you need at least Background DELETE rights on underlying tables and views.

A role does not "see" that a table is a Component Table. You can define Table Rights and Column Rights on Component Tables in just the same way as you can define Table Rights and Column Rights on Database Tables:

A difference with Database Tables is that Component Tables exist only in the USoft layer and not as physical database tables. When you add or change authorisation on Component Tables, by definition you never need to (re)run an Update Application Rights routine in USoft Authorizer in order to update database grants.

It could be that all of the 4 access rights for tables (SELECT, INSERT, UPDATE, DELETE) apply to a Component Table. It could also be that only a subset applies. This depends on implementation details of the Component associated with the Component Table. Best practice is to define access rights only for operations that are actually implemented, and to give any remaining rights on the Component Table the scope of None.

A role does not "see" that a table is an Interface Table. You can define Table Rights and Column Rights on Interface Tables in just the same way as you can define Table Rights and Column Rights on Database Tables:

Interface Tables, like Database Tables, exist as physical database tables. When you add or change authorisation on Interface Tables, you may need to (re)run an Update Application Rights routine in USoft Authorizer in order to update database grants.

Interface Tables reflect a concern with development-time modularisation, but authorisation is concerned only with the run-time use of tables and views. For this reason, when you come to define authorisation, the distinction between Interface Tables and other tables and views is no longer relevant.

It is possible that you have made valuable role definition decisions in the Definer of the module that is the provider of the Interface Table. In this case, it is convenient to give a role the entire collection of access rights of a role in the module. Do this by adding a module right.