Jump to: navigation, search

Difference between revisions of "MRO Objects (Client)"

(→‎Work Progress)
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[File:MRO_WinX.png|thumb|alt=MRO Child List UI (WinX)|MRO UI (WinX)]]
 
[[File:MRO_WinX.png|thumb|alt=MRO Child List UI (WinX)|MRO UI (WinX)]]
−
[[File:MRO_MAUI1.jpeg|thumb|alt=MRO Child List UI (Android)|MRO UI (Android)]]
+
[[File:MRO_MAUI1.jpeg|thumb|alt=MRO Child List UI (Mobile)|MRO UI (Mobile)]]
−
The WinX client UI displays MRO configured objects like any other root- or child-object enriched by some additional logic and features.
+
  
−
== Basic User Interface ==
+
The WinX and Mobile clients display MRO objects like other root or child objects, with additional MRO-specific indicators, controls, and evaluation logic.
−
The representation of MRO features comprises some indicators and interactive controls. In the {{UBIK}} child list, the main object displays cumulated technical and organisational status as well as the overall work progress based on the underlying data branch. Objects classified as MRO objects in general provide indicators for the MRO status. This means the status is shown next to the main icon of a child-/details-/documents-page as well as next to the icons of the child list items:
+
  
−
=== Technical Status ===
+
This page documents behaviour that is shared by multiple MRO objects in the clients. The MRO object model, task-specific behaviour, and relevant technical properties are documented on [[MRO (Plugin)]]. For the complete task-type catalog, see [[MRO (Plugin)#MRO Task Types|MRO Task Types]].
  
−
The technical status indicator is shown on all objects that represent a technical state or receive the technical status from subsequent objects in the underlying data branch. If e.g. a inventory object is reported as damaged, its parent objects will all display the exclamation mark symbol to indicate that a problem was reported in the child items.
+
{| class="wikitable"
 +
|-
 +
! Page !! Scope
 +
|-
 +
| [[MRO (Plugin)]] || MRO concepts, task types, task-specific behaviour, and relevant technical properties
 +
|-
 +
| '''MRO Objects (Client)''' || Common client presentation, status indicators, locking, and behaviour shared by multiple MRO objects
 +
|}
  
−
[[File:TechStats_WinX.png|100px|Technical Status Indicator (Winx & Mobile)]]
+
== Basic User Interface ==
  
−
=== Organisational Status ===
+
The MRO user interface provides status indicators and interactive controls. In the {{UBIK}} child list, an MRO object can display its accumulated technical status, organisational status, and overall work progress based on its underlying data branch. These indicators are shown next to the main icon on child, details, and documents pages as well as next to the icons of child-list items.
−
The organisational status indicates the amount of confirmed work within the data branch, including already confirmed work packages as well as tasks that are locked by their owning work package. The organisational status indicator is displayed on all objects that represent an organisational state or receive the organisational status from subsequent objects in the underlying data branch, and visualizes the amount of confirmed work performed within that branch.
+
−
<gallery>
+
−
File:OrgaStatusIndicatorWinX.PNG|Organisational Status Indicator (WinX)
+
−
File:ConfirmedWP_WinX.png|MRO Workpackage Confirmed (Flag) Indicator (WinX)
+
−
File:ConfirmedWP_MAUI.jpeg|MRO Workpackage Confirmed Indicator (Mobile)
+
−
</gallery>
+
  
 +
=== Technical Status ===
  
 +
The technical status indicator is shown on objects that represent a technical state or receive the technical status from subsequent objects in the underlying data branch. For example, if an inventory object is reported as damaged, its parent objects display an exclamation-mark indicator to show that a problem was reported by a child object.
  
 +
[[File:TechStats_WinX.png|100px|Technical Status Indicator (WinX and Mobile)]]
  
 +
=== Organisational Status ===
  
−
 
+
The organisational status represents the amount of confirmed work in the data branch. This includes confirmed Work Packages as well as Tasks that are locked by their owning Work Package. The indicator is shown on objects that represent an organisational state or receive the organisational status from subsequent objects.
−
 
+
−
=== Work Progress ===
+
−
The work progress is calculated from the current work progress and from the progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.
+
−
 
+
−
{{Version/WinXSince|5.0}} {{Version/MobileSince|5.0}} By default, the progress is displayed with maximum one decimal place. For example, 99.75% is displayed as 99.8%. The format string used to achieve this is <code>{0:0.#}%</code>.
+
−
 
+
−
If other numeric formats are preferred in your usecases, you can refer to [https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings custom numeric format strings] for more information. The template to customize for this is the UBIKMROProgressBadge within UBIKThemes.
+
−
 
+
−
{{Clear}}
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
== MRO Objects ==
+
−
A set of specific objects can be used to provide the required structure for MRO:
+
−
 
+
−
=== Task Owner ===
+
−
A [[MROCLS_MRO_TASKOWNER|Task Owner]] is an object having a substructure of jobs to be done. It can have a tree of other task owners or work packages underneath that will update the status of the task owner. This status consists of technical, organisational and progress information. With a task owner a user can get an overview of all the work to be done in the underlying job structure.
+
−
 
+
−
=== Work Package===
+
−
A [[MROCLS_MRO_WORKPACKAGE|Work Package]] is a collection of objects to collect and summarize other task owning objects, workpackages, or tasks. A simple workpackage has a certain amount of tasks that have to be finished in order to confirm the workpackage as done. More complex workpackages can also own other underlying workpackages that have to be confirmed.  Confirming a workpackage itself requires a progress of 100% of all related tasks, as well as 100% confirmed sub work packages.
+
  
 
<gallery>
 
<gallery>
−
File:ConfirmingWP_WinX.png|MRO Workpackage confirm button (WinX)
+
File:OrgaStatusIndicatorWinX.PNG|Organisational Status Indicator (WinX)
−
File:MRORevoke_WinX.png|MRO Workpackage revoke confirmation button (WinX)
+
File:ConfirmedWP_WinX.png|Confirmed Work Package flag (WinX)
−
File:ConfirmingWP_MAUI.jpeg|MRO Workpackage confirm button (Android)
+
File:ConfirmedWP_MAUI.jpeg|Confirmed Work Package indicator (Mobile)
−
File:MRORevoke_MAUI.jpeg|MRO Workpackage revoke confirmation button (Android)
+
 
</gallery>
 
</gallery>
  
−
=== Task ===
+
=== Work Progress ===
−
A [[MROCLS_MRO_TASK|Task]] is an object reporting a certain progress to the owning workpackage. There are several specialized types of task objects. All kinds of tasks have a property called '''VALUE''' in common. It is very important, that this property is able to be validated. Therefore, a MetaAttribute (providing a validation timestamp by default) has to be attached on the used MetaProperty.
+
  
−
On both clients, a Task can be reverted by clicking twice on the Not Applicable button.
+
Work progress is calculated from the object's current progress and the progress accumulated from subsequent objects in the underlying data branch. The indicator shows the amount of work completed in that branch.
  
 +
{{Version/WinXSince|5.0}} {{Version/MobileSince|5.0}} By default, progress is displayed with no more than one decimal place. For example, 99.75% is displayed as 99.8%. The format string used for this is <code>{0:0.#}%</code>.
  
 +
For other numeric formats, see [https://learn.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings custom numeric format strings]. The template used to customize the presentation is '''UBIKMROProgressBadge''' in '''UBIKThemes'''.
  
−
{{Attention|The MetaProperty ''VALUE'' has to use [[Attributes]] in order to be validated. Otherwise, the calculation of work progress will not be possible.}}
 
−
 
−
==== Measurement Task ====
 
−
 
−
A [[MROCLS_MRO_MEASUREMENT_TASK|Measurement Task]] inherits from [[MROCLS_MRO_TASK|Task]] and documents a measured value (e.g. read from a pressure gauge). Therefore, clicking the value on the shown task opens an editor to enter the desired value. If no value was entered before, an empty line will be shown. Once a value has been entered, the task is finished. Alternatively, the task can also be closed by the option ''Not Applicable'' to document the situation of not being able to fullfill the measurement (e.g. the pressure gauge is broken). An additional small value indicator below the main value can report e.g. the previously entered value. The behaviour of this previous value indicator has to be specified separately in the customizing.
 
 
{{Clear}}
 
{{Clear}}
  
−
<gallery widths=497px heights=69px>
+
[[Category:Android|MRO Objects (UBIK WinX)]]
−
File:Measurment Task Empty UWP.png|Measurement Task without a reported value (WinX)
+
[[Category:Client|MRO Objects (Client)]]
−
File:Measurment Task Not Empty UWP.png|Measurement Task with a reported value (WinX)
+
[[Category:Mobile|MRO Objects (Client)]]
−
File:Measurment Task Empty Android.jpg|Measurement Task without a reported value (Android)
+
[[Category:Pages with broken file links|MRO Objects (Client)]]
−
</gallery>
+
[[Category:WinX|MRO Objects (UBIK WinX)]]
  
 +
== MRO Objects ==
  
 +
The MRO object model consists of Task Owners, Work Packages, Tasks, and specialized task types. For the object definitions and technical properties, see [[MRO (Plugin)#MRO Objects|MRO Objects]].
  
 +
=== Task Owner ===
  
 +
A [[MROCLS_MRO_TASKOWNER|Task Owner]] gives users an overview of the work in its underlying structure. The client displays the technical status, organisational status, and work progress accumulated from its subordinate Task Owners and Work Packages.
  
−
==== Progress Task ====
+
For the Task Owner definition, see [[MRO (Plugin)#Task Owner|Task Owner]].
  
−
[[MROCLS_MRO_PROGRESS_TASK| Progress Task]] inherits from [[MROCLS_MRO_MEASUREMENT_TASK|Task]] and reports a certain progress while fullfilling a task. The progress will influence the overall progress of the owning workpackage. If the task cannot be fullfilled, it can also be finished with the option ''Not Applicable''.
+
=== Work Package ===
  
−
There is also an [[MRO_PROGRESS_TASK_EDITOR|alternative editor]] available for progress tasks.{{Version/WinXSince|2.5.4}}
+
The clients provide controls for confirming and revoking the confirmation of a [[MROCLS_MRO_WORKPACKAGE|Work Package]]. A Work Package can be confirmed when its related Tasks have reached the required progress and all subordinate Work Packages have been confirmed.
−
{{Clear}}
+
  
−
<gallery widths=497px heights=69px>
+
<gallery>
−
File:Progress Task UWP.png|Progress Task with a reported work progress (WinX)
+
File:ConfirmingWP_WinX.png|Work Package confirmation button (WinX)
−
File:Progress Task Android.jpg|Progress Task with a reported work progress and a previous progress(Android)
+
File:MRORevoke_WinX.png|Revoke Work Package confirmation (WinX)
 +
File:ConfirmingWP_MAUI.jpeg|Work Package confirmation button (Mobile)
 +
File:MRORevoke_MAUI.jpeg|Revoke Work Package confirmation (Mobile)
 
</gallery>
 
</gallery>
  
 +
For the Work Package definition, see [[MRO (Plugin)#Work Package|Work Package]].
  
 +
=== Task ===
  
 +
A [[MROCLS_MRO_TASK|Task]] reports progress to its owning Work Package. All user-editable MRO Tasks support ''Not Applicable''. In both clients, a completed user-editable Task can be reset by selecting ''Not Applicable'' twice.
  
 +
For the common Task model and value-validation requirement, see [[MRO (Plugin)#Task|Task]].
  
−
==== Check Task ====
+
{{Hint|For the complete list of MRO task types, their properties, and their task-specific client behaviour, see [[MRO (Plugin)#MRO Task Types|MRO Task Types]]. For the available Procedure variants and their workflow execution, see [[MRO (Plugin)#Procedure Task Variants and Workflow Execution|Procedure Task Variants and Workflow Execution]].}}
  
−
A [[MROCLS_MRO_CHECK_TASK|Check Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished by reporting ''Done'' or ''Not Applicable''. This is intended for a simple To-Do task that is either done or not.
+
==== Sequential Task ====
−
{{Clear}}
+
  
−
<gallery widths=497px heights=69px>
+
The [[MROCLS_SEQUENTIALTASK|Sequential Task classification]] defines an order in which Tasks are to be completed. One or more predecessor Tasks can be required to finish before a dependent Task becomes unlocked and editable. A Task can have any number of predecessors.
−
File:Check Task finished UWP.png|Unfinished MRO CheckTask (WinX)
+
−
File:Check Task android.jpg|Not Applicable MRO CheckTask (Android)
+
−
</gallery>
+
  
 +
A Task and its predecessors do not have to belong to the same Work Package. A predecessor can be located elsewhere in the object hierarchy.
  
 +
The state of a Sequential Task is evaluated both online and offline. This allows visible dependent Tasks to update immediately when their predecessors are finished. The server-side state takes precedence in the case described by the first step below.
  
 +
The state is evaluated as follows:
  
 +
# If the server-side state says that the Task is open, it is treated as open and no further local evaluation is performed.
 +
# The client checks whether the Task has predecessors.
 +
# The client attempts to load every predecessor Task.
 +
#* If any predecessor cannot be loaded because it is not available offline, the Task is locked.
 +
# If every predecessor is finished, the Task is open and editable. Otherwise, it is locked.
  
−
==== Inspection Task ====
+
The configured dependency graph must not contain cycles. Tasks within a dependency cycle could never become available for completion.
−
 
+
−
[[MROCLS_MRO_INSPECTION_TASK|Inspection Task]] inherits from [[MROCLS_MRO_TASK|Task]] and is finished, when the user reports with a positive or negative answer or ''Not Applicable'' (e.g. reporting a yes/no answer for existing equipment).
+
−
{{Clear}}
+
−
 
+
−
<gallery widths=497px heights=69px>
+
−
File:Finished Inspection Task UWP.png|Finished MRO InspectionTask (WinX)
+
−
File:Inspection task android.jpg|Finished MRO InspectionTask (Android)
+
−
</gallery>
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
==== Sequential Task ====
+
−
The [[MROCLS_SEQUENTIALTASK|sequential task classification]] allows you to pre-define a sequence in which tasks are to be resolved by users. This means that it is required for one or multiple tasks to be finished in order for other tasks to become "unlocked" and editable. A task can have any number of "predecessors". Predecessors are the tasks that are required to be finished first.
+
−
 
+
−
A task can have predecessors that live anywhere else in the object hierarchy. It is not necessary for a task and its predecessors to be part of the same work package, even though this is likely the most common use case.
+
−
 
+
−
The state of a sequential task is evaluated both offline and online to get the best possible user experience. The user will see dependent tasks update immediately if their successors were finished, if those tasks are currently visible in the UI. There is 1 case in which the server-side state will override the client-side (offline) evaluation, discussed below.
+
−
The state of each sequential task is evaluated the following way:
+
−
 
+
−
# If the server-side state says the task is open, we consider this as the truthful state and don't do any other evaluation.
+
−
# Check if the task has any predecessors.
+
−
# Try to load each predecessor task.
+
−
#* If loading of any predecessor fails (the object is not available offline), the task will be locked.
+
−
# If all predecessor tasks are finished, the task is open and can be edited. Otherwise, the task is locked.
+
−
 
+
−
The customizer setting up the task dependency relations needs to ensure that the dependencies are not cyclical. In this case, it would be impossible for any tasks in the "cycle" to be finished.
+
  
 
'''Example'''
 
'''Example'''
  
−
As a demonstration of this feature, see [[Media:Sequential_tasks_winx.mp4|this video]]. The relations between tasks are defined as in [[Media:Task_relations.png|this image]], starting at A1 and A2, which are not dependent on any other tasks. The lines (from left to right) indicate dependencies. This means that B2 has tasks A1 and A2 as its predecessors, for example.
+
See [[Media:Sequential_tasks_winx.mp4|this video]] for a demonstration. The Task relations are illustrated in [[Media:Task_relations.png|this image]]. Tasks A1 and A2 do not depend on other Tasks. The lines from left to right represent dependencies; for example, B2 has A1 and A2 as predecessors.
−
 
+
  
 
==== Grouped Task {{Version/WinXSince|4.2}}{{Version/XamarinSince|4.2}} ====
 
==== Grouped Task {{Version/WinXSince|4.2}}{{Version/XamarinSince|4.2}} ====
−
Sometimes, not all tasks have to be finished. More specifically, there might be a predefined condition where you only need to finish a certain number of tasks among a group of them. These are known in {{UBIK}} as [[MROCLS_GROUPEDTASK|grouped tasks]].
 
  
−
The idea is, a group of tasks can be defined as siblings to each other and they also share the same server configured threshold. When the number of finished tasks among that group exceeds the threshold, the entire group is considered as no longer necessary. When reflected in the overall status of the task owner(s), these tasks would appear as if they are finished.
+
The [[MROCLS_GROUPEDTASK|Grouped Task classification]] is used when only a configured number of Tasks from a group have to be finished. The Tasks are siblings and share a server-configured threshold. When the number of finished Tasks reaches the threshold, the remaining Tasks in the group are considered no longer necessary. For the accumulated status of the owning objects, those Tasks are treated as if they were finished.
  
−
{{Hint|Technically speaking, the finished status is completely independent from the not necessary status on a task. A grouped task which is no longer necessary can be both finished or not yet finished. In other words, users don't have to finish a not necessary grouped task, but they still can.}}
+
{{Hint|The finished state and the no-longer-necessary state are independent. A Grouped Task that is no longer necessary can be either finished or unfinished. Users do not have to finish it, but they still can.}}
  
−
{{Hint|The precise status calculation for grouped tasks and their task owners requires the knowledge of all siblings tasks. Imagine 2 out of 3 tasks must be finished but the client only knows 1 in total and the others are only available at the server at that time. This makes it impossible to draw conclusions whether the task(s) should be necessary or not. Under such circumstances, the local status calculation is done as if these are just regular tasks.}}
+
{{Hint|The precise status calculation requires information about all sibling Tasks. If some siblings are not available offline, the client cannot determine whether the threshold has been reached. In this situation, the local status calculation treats the available objects as regular Tasks.}}
  
−
{{Hint|Like with the other MRO objects, the client always chooses the best available statuses for grouped tasks to present to the users. More specifically, it uses the statuses calculated by the server when the client is not offline and there are no uncommitted local changes on the involved objects. Otherwise, it uses the statuses calculated locally to the best of its knowledge.}}
+
{{Hint|The client uses the best available status. It uses the status calculated by the server when the client is online and there are no uncommitted local changes on the involved objects. Otherwise, it calculates the status locally based on the available information.}}
  
−
A task can also be a grouped and a sequential one at the same time. In such a case, the grouped nature of the sibling tasks will affect the way the task sequence completes.
+
A Task can be both grouped and sequential. In this case, the group threshold affects when a dependent Task becomes available.
  
−
For example, task A1, A2 and A3 are 3 grouped sibling tasks and only 1 of them needs to be finished. At the same time, they are all predecessors of task B. Normally, all predecessors must be finished (and locked) before task B becomes the next one in the sequence and therefore unlocked. In this case, however, as soon as one of the predecessors is finished, all three become unnecessary (and locked) and task B unlocks as a result of that.
+
For example, Tasks A1, A2, and A3 can form a group in which only one Task has to be finished. If all three are predecessors of Task B, finishing one of them causes the group threshold to be reached. All three predecessors become no longer necessary and locked, and Task B becomes unlocked.
−
 
+
−
 
+
−
==== Supervisor Task {{Version/XamarinSince|4.8}} ====
+
−
As the name suggests, supervisor tasks are those that must be finished under supervision. When users want to finish a [[MROCLS_MRO_SUPERVISOR_TASK|supervisor task]], they must hand over their work devices to a supervisor. The latter checks the work status and scans an NFC tag if the work is approved. If the [[MROCLS_MRO_SUPERVISOR|supervisor]] has sufficient permissions for the task and the correct supervisor PIN is given, the task gets unlocked and the users can proceed to finish it.
+
−
 
+
−
<gallery widths=300px heights=300px>
+
−
File:UI_Xamarin_Supervisor_Task_Before_Verification.jpg|Supervisor Task Before Verification/Unlocking (Mobile)
+
−
File:UI_Xamarin_Supervisor_Task_Enter_PIN.jpg|Supervisor Task Enter PIN (Mobile)
+
−
File:UI_Xamarin_Supervisor_Task_After_Verification.jpg|Supervisor Task After Verification/Unlocking (Mobile)
+
−
</gallery>
+
−
 
+
−
A thing to note is that while the need to verify a supervisor task can be seen as a type of locking, it's certainly not the only reason for a [[Locked_Objects|locked object]]. This means a supervisor task can remain locked (although for different reasons) even after a supervisor has successfully verified it. This can often be the case if you use it in combination with other features such as [[MRO_Objects_(Client)#Sequential_Task|sequential tasks]], [[User_Rights|user rights]].
+
−
 
+
−
{{Hint|For security reasons, the verification process is cancelled if the supervisor enters the wrong PIN for three times. Scanning the tag again is required in that case.}}
+
−
{{Hint|A setting controls [[RFID_tags#Choose_which_information_to_use_from_a_tag|which information in a scanned tag is used]] during this process.}}
+
−
 
+
−
==== Signature Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====
+
−
 
+
−
The Signature Task is a task type that is completed by capturing a handwritten signature from the user. The task contains an editor field that serves as the entry point for the signing process. When the user clicks (or taps) on the editor field, a signature dialog opens. Within this dialog, the user can provide their signature. After confirming the input, the signature is saved and the task is automatically marked as completed.
+
−
 
+
−
If the task is signed while the client is online:
+
−
* The User (signee) is resolved immediately by the server and displayed.
+
−
* The ValidationTimestamp is generated and displayed.
+
−
* Both values are shown directly in the editor field after signing.
+
−
 
+
−
{{Hint|The User only gets resolved by the server and displayed once you're in online mode}}
+
−
 
+
−
If the displayed User and/or ValidationTimestamp cannot be fully shown due to limited space in the editor field, the complete information can be accessed via a Popup.
+
−
To show the Popup displaying the full User and ValidationTimestamp without truncation, click on the editor field.
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
 
+
−
==== Picture Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====
+
−
 
+
−
A [[MROCLS_PICTURE_TASK|picture task]] is a check task which can only be finished when it has at least one child document containing a valid file. In the UI, an additional photo button is presented next to the check so users can easily take photos before finishing the tasks.
+
−
* As any other objects, picture tasks can carry and display [[SYSCLS_CHILDINFOOWNER|child count information]]. But that is not a mandatory part of the feature. Even when it's not configured and not visible in the UI, you can still finish the tasks.
+
−
* In WinX/UWP, the UI also presents an expander which allows you to display the child documents of picture tasks. This is not present by default in the Mobile app due to the screen size limit but [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel#Show_NextLevel_Children.2FDocuments|can be easily customized]].
+
−
 
+
−
{{Hint|The task is named as such because pictures are the most commonly used types, but the child documents can be of other types as well. }}
+
−
 
+
−
When a user tries to finish a picture task by tapping the check, the app might perform some data synchronization first if in online mode, which includes
+
−
* Syncing the child objects (including documents) of the task.
+
−
* Downloading the file(s) of the child documents.
+
−
During data synchronization, the check button on that task turns into a wait indicator. Afterwards, the app checks if the prerequisites to finish the task are met.
+
−
* If there are no child documents or no local files for the child documents, the task remains unfinished and the user gets informed about the reasons.
+
−
* Otherwise, the task gets finished and the photo button gets disabled.
+
−
 
+
−
{{Hint|Setting NA (not applicable) on a picture task is always possible, regardless of the condition of child documents.}}
+
−
 
+
−
==== Numeric Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====
+
−
 
+
−
A [[MROCLS_MRO_NUMERIC_TASK|numeric task]] is a task which records a double value (e.g. from a temperature sensor). Entering the value (including Not Applicable) completes the task.
+
−
* The value is compared against an accaptable value range which is not editable on the client.
+
−
* Deviation from this range results in visual feedback as well as the [[#Tech Status|tech status]] being set to display an issue.
+
−
* If the configured value range is invalid (e.g. min > max) and the user enters a value, the [[#Tech Status|tech status]] will also be set to display an issue.
+
−
* A numeric task also has a special value unit that can be set per task instance. If set, it overrides the standard value unit defined on the [[MetaProperty#Unit_Item|MetaProperty]].
+
−
 
+
−
==== Pick List Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====
+
−
 
+
−
A [[MROCLS_PICK_LIST_TASK|Pick List task]] looks and behaves the same like a standard Integer Task with SelectiveList. Other than the standard Integer Task, the Pick List Task has an [[UBIK_Active_Lists|Active List]] defined on instance level to pick from for its value property. The task counts as finished as soon as a list item has been selected, or when pressing ''Not Applicable''.
+
  
 
==== Procedure Tasks {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====
 
==== Procedure Tasks {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====
  
−
Procedure tasks are [[#Sequential_Task|sequential tasks]] that can define a more complex workflow with task branching. There are three specific types of procedure tasks: [[MRO_(Plugin)#Switch_Start_Task|switch (start) tasks]], [[MRO_(Plugin)#Switch_End_Task|switch end tasks]] and [[MRO_(Plugin)#Calculation_Task|calculation tasks]].
+
Procedure Tasks are specialized [[#Sequential Task|Sequential Tasks]] that can also use [[#Grouped Task|Grouped Task]] behaviour and branching within a Procedure Workpackage. Their task-specific behaviour and workflow execution are documented on the Plugin page to avoid duplicating the canonical task documentation.
−
 
+
−
As a simple example, you can configure several predecessor tasks to measure the temperatures of different parts of an equipment and then a follow-up calculation task to compute the average of them. Then a follow-up of that can be a switch task which determines the follow-up task branch. If the average temperature is above 30°C, the follow-up task is to turn on the cooling mechanism. The other branch can be directly the end of the switch, but it can also include further switches depending on the actual required workflows. The technical details of these tasks can be found in the links above.
+
−
 
+
−
For both switch (start) and calculation tasks, a symbol is displayed in the UI to reflect its following evaluation status.
+
−
* Finished: The task is automatically executed/evaluated successfully;
+
−
* Error: The task was automatically executed/evaluated but resulted in an error.
+
−
{{Hint|Technically speaking, there's a pending status as well for when a procedure task is not yet automatically executed/evaluated. But the UI doesn't additionally display anything for that.}}
+
−
 
+
−
When a predecessor switch task is not yet finished, its follow-up procedure tasks are hidden because it's simply unknown which ones are relevant for the users. Once it's finished, the branch to follow appears while the other branch remains hidden. Additionally, all procedure tasks in that other branch get set to NA (not applicable).
+
  
−
{{Hint|Procedure tasks are meant to execute automatically without user inputs as soon as their predecessor(s) is/are finished. However, the finishing of such a predecessor task must be triggered by the users. If such a predecessor task becomes finished due to e.g. a server update, the follow-up procedure related workflow does not trigger. This is an intentional design to avoid having the workflow triggered in the name of the users even when they are not responsible for or even aware of it. }}
+
{{Hint|For Procedure variants and workflow execution, see [[MRO (Plugin)#Procedure Task Variants and Workflow Execution|Procedure Tasks]]. For the complete list of base task types, see [[MRO (Plugin)#MRO Task Types|MRO Task Types]].}}
  
 +
=== MRO Objects with Project Information (WinX only) {{Version/WinXSince|2.5.4}} ===
  
 
{{DeprecatedStartTag|parameter=Please refer to [[Main_Page]] for the most recent information.}}
 
{{DeprecatedStartTag|parameter=Please refer to [[Main_Page]] for the most recent information.}}
  
 +
[[File:UI_WinX_MRO_ProjectInfo.png|thumb|MRO Object with Project Information (WinX)]]
  
 +
An MRO object other than a Task can contain [[MROCLS_PROJECTINFORMATION|project information]]. In this case, the project information and MRO progress are displayed in a bar chart. The start and end dates are displayed on the progress bar. Its length and position, together with the current-date marker, indicate the timeline.
  
 +
{{Clear}}
  
−
 
−
 
−
 
−
=== MRO objects with project information (WinX only) {{Version/WinXSince|2.5.4}} ===
 
−
[[File:UI_WinX_MRO_ProjectInfo.png|thumb|MRO Object with Project Info (WinX)]]
 
−
An MRO object (except tasks) might also bring along [[MROCLS_PROJECTINFORMATION|project information]]. In this case, the project information together with the MRO progress are displayed in a bar chart. The start & end dates of the MRO object are displayed on the progress bar. The length and the position of the progress bar, together with the current date mark indicate the timeline.
 
−
{{Clear}}
 
 
{{DeprecatedEndTag}}
 
{{DeprecatedEndTag}}
−
 
−
 
−
 
−
 
−
 
−
 
  
 
== Locking ==
 
== Locking ==
−
When an (MRO) object is locked, editing it becomes impossible. More details about [[Locked_Objects|locked objects]].
 
  
 +
When an MRO object is locked, it cannot be edited. For further information, see [[Locked Objects|Locked Objects]].
  
 +
== See also ==
  
−
 
−
== See also ==
 
 
* [[MRO (Plugin)]]
 
* [[MRO (Plugin)]]
 
* [[MROCLS_PROJECT]]
 
* [[MROCLS_PROJECT]]
Line 273: Line 147:
 
* [[MROCLS_SEQUENTIALTASK]]
 
* [[MROCLS_SEQUENTIALTASK]]
 
* [[MROCLS_GROUPEDTASK]]
 
* [[MROCLS_GROUPEDTASK]]
−
* [[MROCLS_MRO_CHECK_TASK]]
+
* [[MRO (Plugin)#Procedure Task Variants and Workflow Execution|Procedure Tasks]]
−
* [[MROCLS_MRO_INSPECTION_TASK]]
+
−
* [[MROCLS_MRO_MEASUREMENT_TASK]]
+
−
* [[MROCLS_MRO_PROGRESS_TASK]]
+
 
* [[MROCLS_MRO_TASK]]
 
* [[MROCLS_MRO_TASK]]
 
* [[MROCLS_MRO_TASKOWNER]]
 
* [[MROCLS_MRO_TASKOWNER]]
 
* [[MROCLS_MRO_WORKPACKAGE]]
 
* [[MROCLS_MRO_WORKPACKAGE]]
−
* [[MROCLS_PROCEDURE#Procedure Workpackage]] (Classification)
 
−
* [[MROCLS_SWITCH_TASK#Switch Task]] (Classification)
 
−
* [[MROCLS_SWITCH_END_TASK#Switch End Task]] (Classification)
 
−
* [[MROCLS_CALCULATION_TASK#Calculation Task]] (Classification)
 
−
* [[MROCLS_PICK_LIST_TASK]] (Classification)
 
  
 
[[Category:Android|MRO Objects (UBIK WinX)]]
 
[[Category:Android|MRO Objects (UBIK WinX)]]

Latest revision as of 14:31, 17 August 2026

MRO Child List UI (WinX)
MRO UI (WinX)
MRO Child List UI (Mobile)
MRO UI (Mobile)

The WinX and Mobile clients display MRO objects like other root or child objects, with additional MRO-specific indicators, controls, and evaluation logic.

This page documents behaviour that is shared by multiple MRO objects in the clients. The MRO object model, task-specific behaviour, and relevant technical properties are documented on MRO (Plugin). For the complete task-type catalog, see MRO Task Types.

Page Scope
MRO (Plugin) MRO concepts, task types, task-specific behaviour, and relevant technical properties
MRO Objects (Client) Common client presentation, status indicators, locking, and behaviour shared by multiple MRO objects

Basic User Interface

The MRO user interface provides status indicators and interactive controls. In the UBIK® child list, an MRO object can display its accumulated technical status, organisational status, and overall work progress based on its underlying data branch. These indicators are shown next to the main icon on child, details, and documents pages as well as next to the icons of child-list items.

Technical Status

The technical status indicator is shown on objects that represent a technical state or receive the technical status from subsequent objects in the underlying data branch. For example, if an inventory object is reported as damaged, its parent objects display an exclamation-mark indicator to show that a problem was reported by a child object.

Technical Status Indicator (WinX and Mobile)

Organisational Status

The organisational status represents the amount of confirmed work in the data branch. This includes confirmed Work Packages as well as Tasks that are locked by their owning Work Package. The indicator is shown on objects that represent an organisational state or receive the organisational status from subsequent objects.

  • Organisational Status Indicator (WinX)

  • Confirmed Work Package flag (WinX)

  • Confirmed Work Package indicator (Mobile)

Work Progress

Work progress is calculated from the object's current progress and the progress accumulated from subsequent objects in the underlying data branch. The indicator shows the amount of work completed in that branch.

By default, progress is displayed with no more than one decimal place. For example, 99.75% is displayed as 99.8%. The format string used for this is {0:0.#}%.

For other numeric formats, see custom numeric format strings. The template used to customize the presentation is UBIKMROProgressBadge in UBIKThemes.

MRO Objects

The MRO object model consists of Task Owners, Work Packages, Tasks, and specialized task types. For the object definitions and technical properties, see MRO Objects.

Task Owner

A Task Owner gives users an overview of the work in its underlying structure. The client displays the technical status, organisational status, and work progress accumulated from its subordinate Task Owners and Work Packages.

For the Task Owner definition, see Task Owner.

Work Package

The clients provide controls for confirming and revoking the confirmation of a Work Package. A Work Package can be confirmed when its related Tasks have reached the required progress and all subordinate Work Packages have been confirmed.

  • Work Package confirmation button (WinX)

  • Revoke Work Package confirmation (WinX)

  • Work Package confirmation button (Mobile)

  • Revoke Work Package confirmation (Mobile)

For the Work Package definition, see Work Package.

Task

A Task reports progress to its owning Work Package. All user-editable MRO Tasks support Not Applicable. In both clients, a completed user-editable Task can be reset by selecting Not Applicable twice.

For the common Task model and value-validation requirement, see Task.

IC Hint square.pngFor the complete list of MRO task types, their properties, and their task-specific client behaviour, see MRO Task Types. For the available Procedure variants and their workflow execution, see Procedure Task Variants and Workflow Execution.

Sequential Task

The Sequential Task classification defines an order in which Tasks are to be completed. One or more predecessor Tasks can be required to finish before a dependent Task becomes unlocked and editable. A Task can have any number of predecessors.

A Task and its predecessors do not have to belong to the same Work Package. A predecessor can be located elsewhere in the object hierarchy.

The state of a Sequential Task is evaluated both online and offline. This allows visible dependent Tasks to update immediately when their predecessors are finished. The server-side state takes precedence in the case described by the first step below.

The state is evaluated as follows:

  1. If the server-side state says that the Task is open, it is treated as open and no further local evaluation is performed.
  2. The client checks whether the Task has predecessors.
  3. The client attempts to load every predecessor Task.
    • If any predecessor cannot be loaded because it is not available offline, the Task is locked.
  4. If every predecessor is finished, the Task is open and editable. Otherwise, it is locked.

The configured dependency graph must not contain cycles. Tasks within a dependency cycle could never become available for completion.

Example

See this video for a demonstration. The Task relations are illustrated in this image. Tasks A1 and A2 do not depend on other Tasks. The lines from left to right represent dependencies; for example, B2 has A1 and A2 as predecessors.

Grouped Task

The Grouped Task classification is used when only a configured number of Tasks from a group have to be finished. The Tasks are siblings and share a server-configured threshold. When the number of finished Tasks reaches the threshold, the remaining Tasks in the group are considered no longer necessary. For the accumulated status of the owning objects, those Tasks are treated as if they were finished.

IC Hint square.pngThe finished state and the no-longer-necessary state are independent. A Grouped Task that is no longer necessary can be either finished or unfinished. Users do not have to finish it, but they still can.
IC Hint square.pngThe precise status calculation requires information about all sibling Tasks. If some siblings are not available offline, the client cannot determine whether the threshold has been reached. In this situation, the local status calculation treats the available objects as regular Tasks.
IC Hint square.pngThe client uses the best available status. It uses the status calculated by the server when the client is online and there are no uncommitted local changes on the involved objects. Otherwise, it calculates the status locally based on the available information.

A Task can be both grouped and sequential. In this case, the group threshold affects when a dependent Task becomes available.

For example, Tasks A1, A2, and A3 can form a group in which only one Task has to be finished. If all three are predecessors of Task B, finishing one of them causes the group threshold to be reached. All three predecessors become no longer necessary and locked, and Task B becomes unlocked.

Procedure Tasks

Procedure Tasks are specialized Sequential Tasks that can also use Grouped Task behaviour and branching within a Procedure Workpackage. Their task-specific behaviour and workflow execution are documented on the Plugin page to avoid duplicating the canonical task documentation.

IC Hint square.pngFor Procedure variants and workflow execution, see Procedure Tasks. For the complete list of base task types, see MRO Task Types.

MRO Objects with Project Information (WinX only)

TimeAlert Icon.PNG
THIS WIKI AREA IS DEPRECATED
This content is no longer being maintained and may be outdated. Please refer to Main Page for the most recent information.


MRO Object with Project Information (WinX)

An MRO object other than a Task can contain project information. In this case, the project information and MRO progress are displayed in a bar chart. The start and end dates are displayed on the progress bar. Its length and position, together with the current-date marker, indicate the timeline.

END OF DEPRECATED AREA



Locking

When an MRO object is locked, it cannot be edited. For further information, see Locked Objects.

See also

Retrieved from "https://wiki.augmensys.com/index.php?title=MRO_Objects_(Client)&oldid=30455"