|
See Also
For each right you can
indicate its scope plus any conditions. The following table shows
certain rights, their scope, and foreground and/or background
conditions applying to the rights. The examples that follow are
based on a data model of a fictitious Travel Agency. The right
specifications have little meaning in isolation, but they are
listed as such for reasons of simplicity.
Possible Combinations of Scope
and Conditions
|
|
Scope
|
Foreground Condition?
|
Background Condition?
|
|
1
|
None
|
Not applicable
|
Not applicable
|
|
2
|
Foreground and Background
|
No
|
No
|
|
3
|
Foreground and Background
|
Yes
|
No
|
|
4
|
Foreground and Background
|
Yes
|
Yes
|
|
5
|
Background Only
|
Not applicable
|
No
|
|
6
|
Background Only
|
Not applicable
|
Yes
|
These combinations can be
described as follows:
| 1.
|
Nothing is granted. For example, you want to completely deny a
certain right to the end-user. This option is particular useful in
case a table consists of a lot of columns and you want to deny
access to a small number of its columns. At the table level specify
the appropriate right with scope "foreground and background", then
specify the same right with scope "none" for the applicable
columns, overruling the more generic table right. |
Example
Give user group GUIDES the
right to select every column of the PERSON table except the STAFF
column (a subtype indicator column) of table PERSON.
|
Table:
|
PERSON
|
|
User group:
|
GUIDES
|
|
Right:
|
Select
|
|
Scope:
|
Foreground and Background
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
|
Column Name:
|
STAFF
|
|
Column Right:
|
Select
|
|
Scope:
|
None
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
| 2.
|
The right is completely granted to the user group. |
Example
Allow user group FRONT_OFFICE
to make changes (updates) to the RESERVATION table.
|
Table:
|
RESERVATION
|
|
User group:
|
FRONT_OFFICE
|
|
Right:
|
Update
|
|
Scope:
|
Foreground and Background
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
|
Column Name:
|
Not Applicable
|
|
Column Right:
|
Not Applicable
|
|
Scope:
|
Not Applicable
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
NOTE:
Changes can be caused by
corrective constraints fired because the end-user touches data
originating in another table. By specifying scope Foreground and
Background on table RESERVATION these kind of background
manipulations are allowed to be performed
| 3.
|
The right is granted completely, but is conditional in the
foreground. |
Example
Allow user group FRONT_OFFICE
to make changes (updates) to the RESERVATION table but restrict
this right to non canceled Reservations for Scheduled Tours not yet
started.
|
Table:
|
RESERVATION
|
|
User group:
|
FRONT_OFFICE
|
|
Right:
|
Update
|
|
Scope:
|
Foreground and Background
|
|
Foreground Condition:
|
cancel_date IS NULL
AND EXISTS
(SELECT '' FROM schedtour
s
WHERE s.schedtour_id =
schedtour_id AND s.start_date > SYSDATE)
|
|
Background Condition:
|
Not Applicable
|
|
Column Name:
|
Not Applicable
|
|
Column Right:
|
Not Applicable
|
|
Scope:
|
Not Applicable
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
NOTE:
By not specifying a background
condition, background processes such as execution of corrective
constraints, for example, are allowed to make changes to the data
that the end-users are not allowed to make via data windows or the
SQL Command dialog.
| 4.
|
The right is granted completely, but there are conditions in
the foreground as well as the background. |
Example
Assume the situation described
in the previous example is still true, but the condition also
applies to background processes. Corrective constraints are only
allowed to perform manipulations on the RESERVATION table if they
apply to Scheduled Tours not yet started.
|
Table:
|
RESERVATION
|
|
User group:
|
FRONT_OFFICE
|
|
Right:
|
Update
|
|
Scope:
|
Foreground and Background
|
|
Foreground Condition:
|
cancel_date IS NULL
AND EXISTS
(SELECT '' FROM schedtour
s
WHERE s.schedtour_id =
schedtour_id AND s.start_date > SYSDATE)
|
|
Background Condition:
|
cancel_date IS NULL
AND EXISTS
(SELECT '' FROM schedtour
s
WHERE s.schedtour_id =
schedtour_id AND s.start_date > SYSDATE)
|
|
Column Name:
|
Not Applicable
|
|
Column Right:
|
Not Applicable
|
|
Scope:
|
Not Applicable
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
| 5.
|
The right is not granted in the foreground but the user is
allowed to do whatever the right grants him/her to do in the
background. |
Example
Allow user group PLANNING the
right to delete Guide data. Assume a nullifying delete rule applies
to the relationship between the GUIDE and SCHEDTOUR table (this
means that if you delete a parent record in table GUIDE, the
foreign key GUIDE in any of the child records referencing the
parent record in the SCHEDTOUR table is updated to value "null").
Specify a background update right on table SCHEDTOUR to only allow
the Rules Engine to change the foreign key values to "null".
|
Table:
|
RESERVATION
|
|
User group:
|
FRONT_OFFICE
|
|
Right:
|
Update
|
|
Scope:
|
Foreground and Background
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
cancel_date IS NULL
AND EXISTS
(SELECT '' FROM schedtour
s
WHERE s.schedtour_id =
schedtour_id AND s.start_date > SYSDATE)
|
|
Column Name:
|
Not Applicable
|
|
Column Right:
|
Not Applicable
|
|
Scope:
|
Not Applicable
|
|
Foreground Condition:
|
Not Applicable
|
|
Background Condition:
|
Not Applicable
|
NOTE:
End-users cannot empty the
foreign key field using a data window or using SQL Command, when
the update right is only specified in the background.
| 6.
|
The right is not granted in the foreground but the user is
allowed to do whatever the combination of right plus condition
grants him/her to do in the background. |
So, for example, the same
situation exists as in the previous example, but is restricted to
records that pass the condition test.
Note the following:
|
·
|
If no rights have been defined, the user is allowed to do
everything (in the foreground and in the background). |
|
·
|
If a right has been defined, but the scope of the right has
been set to None, then the right is switched off. |
|
