Difference between revisions of "Locked Objects"
| (3 intermediate revisions by one other user not shown) | |||
| Line 6: | Line 6: | ||
=== Locked by [[MRO_Objects_(Client)#Sequential_Task|sequence]] === | === Locked by [[MRO_Objects_(Client)#Sequential_Task|sequence]] === | ||
An MRO task can also be locked if it belongs to a sequential list of tasks that must be completed in order, in this case all tasks but the ones that are currently active in the sequence are locked. | An MRO task can also be locked if it belongs to a sequential list of tasks that must be completed in order, in this case all tasks but the ones that are currently active in the sequence are locked. | ||
| + | === Locked by [[MRO_Objects_(Client)#Supervisor_Task|supervisor]] === | ||
| + | A supervisor task can be additionally locked until a qualified supervisor approves the work and verifies the task by scanning an NFC tag. | ||
| Line 13: | Line 15: | ||
=== Locked by [[User_Rights|user rights]] === | === Locked by [[User_Rights|user rights]] === | ||
If a user does not have the necessary right to write to, or even read the contents of an object this object appears locked. This can apply to groups of objects, single objects or even properties of objects. | If a user does not have the necessary right to write to, or even read the contents of an object this object appears locked. This can apply to groups of objects, single objects or even properties of objects. | ||
| − | === Unlock by | + | === Unlock by code scanning === |
| − | A classification that locks an [[SYSCLS_UNLOCK_BY_SCAN|object]] or [[SYSCLS_UNLOCK_GROUP_BY_SCAN|group of objects]] until a certain | + | A classification that locks an [[SYSCLS_UNLOCK_BY_SCAN|object]] or [[SYSCLS_UNLOCK_GROUP_BY_SCAN|group of objects]] until a certain code is scanned. After the unlock code is scanned it is remembered for 15 minutes allowing access to the locked object. |
| + | |||
== Locking for other reasons == | == Locking for other reasons == | ||
Latest revision as of 12:40, 7 October 2024
In UBIK objects can be locked for multiple reasons, these different types of locking are discussed in this article.
Locking in MRO tasks
Locked by hierarchy
By design, an MRO object is locked if its parent MRO work package is confirmed. This type of locking is applied recursively to all child MRO objects.
Locked by sequence
An MRO task can also be locked if it belongs to a sequential list of tasks that must be completed in order, in this case all tasks but the ones that are currently active in the sequence are locked.
Locked by supervisor
A supervisor task can be additionally locked until a qualified supervisor approves the work and verifies the task by scanning an NFC tag.
Locking through access rights
Locked by exclusive access
Objects may have exclusive access, allowing only a single user to edit it by checking it out, for all other users this objects is locked and can not be edited.
Locked by user rights
If a user does not have the necessary right to write to, or even read the contents of an object this object appears locked. This can apply to groups of objects, single objects or even properties of objects.
Unlock by code scanning
A classification that locks an object or group of objects until a certain code is scanned. After the unlock code is scanned it is remembered for 15 minutes allowing access to the locked object.
Locking for other reasons
Locked during initialization
After logging in objects are locked to prevent them from being edited before the session is fully initialized.
Locked template objects
Objects can be classified as templatable. If the objects "IsTemplate" property is set to read-only the objects properties are locked.
