You can define rights on Logical Views just like you can define rights on Database Tables. Logical Views are Authorization Tables in the same way as database tables:
A difference with Database Tables is that Logical Views exist only in the USoft layer and not as physical database tables. When you add or change authorisation on Logical Views, you do not need to (re)run the Update Application Rights routine that generates database grants.
Logical Views and Database Tables entertain complex relationships, since a Logical View is defined on (based on) one or more Database Tables: Logical Views are said to have underlying tables. A Logical View can also be defined, partly or wholly, on another Logical View.
USoft Authorizer is completely ignorant of these relationships. It simply allows you to define rights (Table Rights and Column Rights) on Database Tables and Logical Views alike.
When you view Authorization Tables in USoft Authorizer, the Logical View Y/N flag allows you to identify an Authorization Table as a Logical View:
Run-time effect of table rights on Logical Views
When you define Table Rights or Column Rights on a Logical View, you must consider the runtime effect of the Logical View's relationship with its underlying table(s) (including any other Logical Views that it is defined on).
The general rule is that it makes no sense to define rights on a Logical View if you do not define at least the same rights on the underlying table.
If you give wider authorisation on a Logical View than on its underlying table, the effect is that the run-time user gets an error message mentioning the underlying table when she attempts to access unauthorised data on the underlying table through the Logical View. This effect is undesirable, especially if you do not want to disclose the name of the underlying table.
In practice, the same rights are often defined on Logical Views and on their underlying tables. It may or may not make sense to define narrower rights on a Logical View than on its underlying table.
Comparing underlying tables and background scope
"Underlying table" is NOT the same as "table with background access". At first sight, you might think that giving access to a Logical View would involve granting foreground access on the Logical View and background access on the underlying table. But "background" and "underlying" are unrelated concepts.
Typically, if you want a user to have foreground access on a Logical View, you also want to give him foreground access on the underlying table. To give a user read‑only access on a Logical View, typically you give him SELECT‑only foreground access on the Logical View AND SELECT‑only foreground access on the underlying table.
If a user is allowed to perform some action that activates a constraint or a relationship attribute that indirectly affects a Database Table or Logical View, but, for some reason, you do not want him to access the table or view otherwise, then you need to grant background access only, regardless of whether the object is a Database Table or a Logical View.