extend and limit the object/link access
Adding / removing alternative holders
In addition to the main holder, both object and link instances may have one or more alternative holders. These users inherit the same access rights defined in the lifecycle stage for the holder except for the "changeholder" privilege.
When a user has the "changeholder" privilege
in the current lifecycle
stage of the object, he can add or remove alternative holders.
In the "Domain Object Manipulation"
client select the objects and push the "Alternative Holders"
button.
An equivalent OOQL command might be
object edit |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 ; |
altholder add 'test.user'; |
Locking and unlocking objects
An object can be locked to prevent
other users from editing it or from editing the files it contains.
Even if the lifecycle allows the other user to edit it, a lock
prevents access to everyone except the person who applied the lock.
This means that other users cannot edit the object field's data
or change its status or manipulate the attached files while the
lock is active.
Locking an object protects the objects contents during editing.
However, if they have the proper access privileges, other users
can view field's values and navigate the connections of the object.
During the file-put operation you can choose to lock the added file;
this lock affects only the single file just attached, but not the
others. The global lock instead, prevents other user to apply any
changes to the object and to all attached files.
There are two levels for locks: object lock and file lock. These are the rules:
- if an object is locked by another user you cannot lock it or perform other operations ( edit, fileput, progress..... )
- if you have the unlock privilege, you may unlock a locked object, but there is a flag to choice if extend or not the unlock to all attached files. So you can unlock the object but leave the locks on the files.
- if a file is locked by another user you can't update (fileput) the same file (or in other terms you can't overwrite the same file in the filespace)
- if you download a locked file, you can unlock it only if you are the locker
- you can upload and lock files even if there are other files locked by other users
Users can apply a global lock to one or more objects by the "Domain
Object Manipulation" client. Simply search/select the objects
and push the "Lock" button.
Locking an object is possible if
it is not already locked by another user and if the user has the
lock privilege activated in the current lifecycle
stage
of the object.
The same result can be obtained with
the following OOQL command :
object lock |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 ; |
It is possible for a locked object to be unlocked by
the user that has locked the object or by a user with unlock
access activated in the current lifecycle
stage .
If there is an existing lock, and you are the user that locked the
object, the lock will be removed from the object. If you are not
the user that locked the object, OBEROn will check for unlock access
and will unlock the object only if you are entitled to do so. Infact,
under some circumstances, it may be necessary to have someone other
than the lock owner remove the lock. For example, a manager may
need to unlock an object locked by an employee who is out sick.
After the lock is removed, other users may apply new locks to obtain
exclusive editing access.
Be aware that unlock access is a very powerful access. By giving
a user/team the unlock access privilege in the
lifecycle stage
you are saying that this user/team can remove anyones lock
including the lock on each attached file.
The unlock OOQL
command
is:
object unlock |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 |
!file ; |
Delegating / revoking the object
access
When a user has the "delegate" privilege
in the current lifecycle
stage
of the object, he can grant accesses on the object
to any other user .
The delegator is allowed to delegate all or a subset of his/her
accesses on the current stage.
This means that, if the delegator has access to perform a specific
action on the object and he grants this access to another user,
this user will have the rights to perform the same action even if
the lifecycle doesn't allow him.
The OOQL commands allow users to:
delegate multiple users for the same object
have more than one delegator for an object
use a key to revoke access without specific information
Users can delegate some accesses
for one or more objects by the "Domain Object Manipulation"
client. Simply search/select the objects and push the "Delegate"
button.
In the "Delegate" form
you can select the destination user and the access privileges granted
to him (choosen with the "Access options" popup). You
can also specify a keyword to associate with the delegation which
identifies it for the future revoke operation. Moreover, if you
select the "Validate" option, you can delegate the user
for all validation actions for which you have access.
An equivalent OOQL command
might be
object
delegate |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 |
user
'user2'
access edit,fileput
key 'EDITandATTACH'; |
For each object you can see the list of delegations
by clicking the "Delegations" button.
You can also remove the delegations for one or more objects by clicking
the "Revoke" button. In the "Revoke" form, you
can specify filters for the delegate user or for the identificative
keyword defined when the grant was made.
There are several approaches to revoke granted
accesses for an object.
- To revoke the grant without specific delegator/delegate
information, you can specify the identificative keyword; an equivalent
OOQL commands
might be:
object
revoke |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 |
key
'EDITandATTACH'; |
- you can revoke all accesses granted by a specific
delegator with:
object
revoke |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 |
delegator
'user1'; |
- you can revoke all accesses granted to a specific
delegate user with:
object
revoke |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 |
user
'user2'; |
- you can remove all granted access on an object, with:
object
revoke |
|
'SR_Help' 'HLP_0000001' '00'
or
'SR_Help' 'HLP_0000001' '00' in 'SR_Space'
or
#00001-2BC91211 |
delegator
all ;
or
user all ;
|
Be aware that revoke access is a very powerful access.
By giving a user/team the revoke access privilege in
the lifecycle stage
you are saying that this user/team can revoke anyones grants.
|