Security | Update Registry entry
Update the contents of one or more fields in the current record when the record is saved if a condition is met (a given value is in a field in the current record). Often (but not exclusively) used to modify Record Level Security security fields.
The Security Update Registry entry allows the contents of one or more fields to be modified whenever a record is saved (inserted or modified) based on the value in a field in the current record. Although any fields may be updated in this way, the Record Level Security (RLS) fields:
SecCanDisplay
SecCanEdit
SecCanDelete
are particularly useful as updating these allows the record security to be modified if a condition in the current record changes.
The database server applies the Security|Update settings whenever a record is saved (i.e. for all insertions and updates). The entries are applied after assignment expressions have been executed and before validation is run. This means that assignment expressions may be used to build a composite value that may be tested by Security|Update settings. For example, it is possible to concatenate two fields into one that may then be checked.
It is also possible to apply sophisticated formula to calculate a field to be checked. For example, you may want to set Security|Update Registry entries based on a range of valuations for an object. You could use an assignment expression to set a value in a field based on the ranges:
Range |
Value |
---|---|
$0 - $1000 | Cheap |
$1001 - $10000 | Average |
$10001 - | Pricey |
You may then use the values, Cheap, Average and Pricey in Security|Update Registry entries.
Note that you cannot use validation code to compute values as the Security|Update entries are applied before validation code is executed.
Usage
This Registry entry can be assigned to users and groups:
Key | User | User | Group | Group | Group | Group |
---|---|---|---|---|---|---|
Key 1 | User
|
User
|
Group
|
Group
|
Group
|
Group
|
Key 2 | user | user | group | group | Default
|
Default
|
Key 3 | Table
|
Table
|
Table
|
Table
|
Table
|
Table
|
Key 4 | table | Default
|
table | Default
|
table | Default
|
Key 5 | Security
|
|||||
Key 6 | Update
|
|||||
Key 7 | column | |||||
Key 8 | value | |||||
Value | settings |
User
|
user | Table
|
table | Security
|
Update
|
column | value | settings |
User
|
user | Table
|
Default
|
Security
|
Update
|
column | value | settings |
Group
|
group | Table
|
table | Security
|
Update
|
column | value | settings |
Group
|
group | Table
|
Default
|
Security
|
Update
|
column | value | settings |
Group
|
Default
|
Table
|
table | Security
|
Update
|
column | value | settings |
Group
|
Default
|
Table
|
Default
|
Security
|
Update
|
column | value | settings |
where:
column |
defines which field should be consulted to look for a matching value. If column is an attachment field
When referencing an attachment field in a Security|Update Registry entry, it is necessary to use a field's Link Column name and a record's IRN. For example:
When an attachment field is referenced as the Value, it is in the format Link Column name=IRN:
|
||||||||||||||||||||||||||||||||||||||||||||||||||
value |
is an EMu based search pattern. If there is a match of the data in column with the value query, then the Registry entry is used and settings is applied. Note: If column contains a table of values, each entry is checked against value. Since value is a pattern, particular attention must be paid if you want to match the complete contents of a field. For example, to match Registration but not Pending Registration, the pattern ^Registration$ should be used. It is important to remember that value operates in the same way as an EMu search term. All comparisons of value are case insensitive. |
||||||||||||||||||||||||||||||||||||||||||||||||||
settings |
is a semicolon separated list of assignments to columns that is applied if there is a match of the data in column with the value query. The format of settings is: column=[+/-]term:[+/-]term:...;column=[+/-]term:... where: |
||||||||||||||||||||||||||||||||||||||||||||||||||
|
If you specify a Security|Update Registry entry to limit the display of a record to group Admin if Record Status is changed to Retired for example, it is necessary to specify a Security|Update Registry entry to account for Record Status changing from Retired to some other condition (Active or null for instance). If no Security|Update Registry entry is specified to account for the change, changing the Record Status from Retired to some other condition will not update the security of the record.
Why?
We've only told EMu what to do if Record Status = Retired; we haven't told EMu what to do if Record Status no longer =Retired.
What does this mean?
If we only specify a Security|Update Registry entry to limit the display of a record to group Admin when Record Status = Retired, changing Record Status to anything other than Retired will not make the record available to other users.
If we want Record Level Security to be adjusted so that users in group Admin are the only ones allowed to edit and delete records that have a record status of Retired, the following entry can be used:
Key | Setting |
---|---|
Key 1 | Group
|
Key 2 | Default
|
Key 3 | Table
|
Key 4 | Default
|
Key 5 | Security
|
Key 6 | Update
|
Key 7 | SecRecordStatus
|
Key 8 | ^Retired$
|
Value | SecCanEdit=Group Admin;SecCanDelete=Group Admin
|
Keys 7 and 8 indicate that the entry only applies where the SecRecordStatus column matches the pattern ^Retired$ (i.e. where the field contains Retired only). If this is not the case, then the Registry entry is ignored. Where a record does match, the SecCanEdit field is set to group Admin. As a leading plus or minus is not supplied, the contents of SecCanEdit are replaced with group Admin. A similar update occurs for SecCanDelete.
A more complex example would involve removing edit access for all users in groups Conservation and Storage when an object is deaccessioned. Let's assume that the column RecObjectStatus contains the word Deaccessioned for objects that are no longer part of our collection. A suitable Registry entry would be:
Key | Setting |
---|---|
Key 1 | Group
|
Key 2 | Default
|
Key 3 | Table
|
Key 4 | ecatalogue
|
Key 5 | Security
|
Key 6 | Update
|
Key 7 | RecObjectStatus
|
Key 8 | ^Deaccessioned$
|
Value | SecCanEdit=-Group Conservation:-Group Storage |
Notice how the terms to set have a leading minus sign, indicating the term (in this case the group name) is to be removed from the field SecCanEdit.
A third example requires all records with an object valuation of High to have group Student removed and group Valuers added for both displaying and editing the record. The field containing the object valuation is ValValuationCode. A suitable Registry entry is:
Key | Setting |
---|---|
Key 1 | Group
|
Key 2 | Default
|
Key 3 | Table
|
Key 4 | ecatalogue
|
Key 5 | Security
|
Key 6 | Update
|
Key 7 | ValValuationCode
|
Key 8 | ^High$
|
Value | SecCanDisplay=-Group Student:+Group Valuers;SecCanEdit=-Group Student:+Group Valuers |
Notice how more than one field may be updated with a single Registry entry. Note also:
- If a term has a leading plus symbol and the term already appears in the field, it is not added again.
- Similarly, if a term has a preceding minus and it does not appear in the field, it is ignored.
In this final example we restrict the display privilege for records that have not been approved for viewing on the intranet to groups Admin, Curator, Storage and Conservation. Once the record has been approved for viewing on the intranet we will allow all users to view the record. In this case two Registry entries are required:
- The first restricts access for records not available on the intranet.
- The second allows access to all users for record available on the intranet.
Suitable Registry entries are:
Key | Setting |
---|---|
Key 1 | Group
|
Key 2 | Default
|
Key 3 | Table
|
Key 4 | ecatalogue
|
Key 5 | Security
|
Key 6 | Update
|
Key 7 | AdmPublishWebPasswordFlag
|
Key 8 | N
|
Value | SecCanDisplay=Group Admin:+Group Curator:+Group Storage:+Group Conservation |
Key | Setting |
Key 1 | Group
|
Key 2 | Default
|
Key 3 | Table
|
Key 4 | ecatalogue
|
Key 5 | Security
|
Key 6 | Update
|
Key 7 | AdmPublishWebPasswordFlag
|
Key 8 | Y
|
Value | SecCanDisplay=Group Default |
Notice how the first term in the first Registry entry (Group Admin) does not have a leading plus or minus, meaning it replaces the current contents of SecCanDisplay. The following terms require a leading plus symbol otherwise they will also clear the current contents rather than adding to the first term. The second Registry entry replaces the contents of SecCanDisplay with group Default (this allows access for everyone).
By using a combination of Registry entries it is possible to produce quite sophisticated and dynamic privilege changes.