tutorial

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 object’s 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 anyone’s 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 anyone’s grants.


<< workflow pending activities  
© 2008-2015 MS Enterprise Solutions | Website Templates by IceTemplates.com
Please Read: Privacy Policy and Terms of Use