Difference between revisions of "MRO Objects (Client)"
m (CHI moved page MRO Objects (UBIK WinX) to MRO Objects (Client)) |
(→MRO Objects) |
||
| Line 99: | Line 99: | ||
| + | ==== Sequential Task ==== | ||
| + | The 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''' | ||
| + | |||
| + | 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. | ||
=== MRO objects with project information (WinX only) {{Version/WinXSince|2.5.4}} === | === MRO objects with project information (WinX only) {{Version/WinXSince|2.5.4}} === | ||
| Line 105: | Line 123: | ||
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. | 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}} | {{Clear}} | ||
| + | |||
| + | [[Category:Android|MRO Objects (UBIK WinX)]] | ||
| + | [[Category:Pages with broken file links|MRO Objects (UBIK WinX)]] | ||
| + | [[Category:WinX|MRO Objects (UBIK WinX)]] | ||
== See also == | == See also == | ||
Revision as of 09:24, 24 April 2018
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 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
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.
thumb|Technical Status Indicator (WinX)
thumb|Technical Status Indicator (Android)
Organisational Status
The organisational status indicator is shown on all objects that represent an organisational state or receive the organisational status from subsequent objects in the underlying data branch. This indicator shows the amount of confirmed work done in the data branch. It can as well display a work package to be already confirmed or show tasks that are already locked by their owning workpackage.
Organisational Status Indicator (WinX)
MRO Workpackage Confirmed (Flag) Indicator (WinX)
Organisational Status Indicator (Android)
MRO Workpackage Confirmed Indicator (Android)
Work Progress
The work progress is shown on all objects that represent the current work progress or receive the work progress cumulated from subsequent objects in the underlying data branch. This indicator shows the amount of work done in the data branch.
thumb|MRO Work Progress Indicator (WinX)
thumb|MRO Work Progress Indicator (Android). The finished overlay is shown once the progress of a MRO object is 100%
MRO Objects
A set of specific objects can be used to provide the required structure for MRO:
Task Owner
A 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 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.
MRO Workpackage confirm button (WinX)
MRO Workpackage revoke confirmation button (WinX)
MRO Workpackage confirm button (Android)
MRO Workpackage revoke confirmation button (Android)
Task
A 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. Additionally the Android client shows a Revert Task button underneath tasks.
Revert Task button (Android)
 | 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 Measurement Task inherits from 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.
Progress Task
Progress Task inherits from 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.
There is also an alternative editor available for progress tasks.
Check Task
A Check Task inherits from 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).
Inspection Task
Inspection Task inherits from 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
The 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
As a demonstration of this feature, see this video. The relations between tasks are defined as in 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.
MRO objects with project information (WinX only)
An MRO object (except tasks) might also bring along 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.
