{{Attention|Existing pre 5.0 XAMLs are not compatible with UBIK Mobile client 5.1. Please refer to [[HowTo:Convert_Xamarin_XAMLs_to_Maui]] for migrating them to the new client.}}

{{Attention|UBIK 5 clients can only connect to {{UBIK}} Servers of [[Version 3.6(Server)|version 3.6]] and higher!}}

{{Attention|The minimum supported OS versions are:
* Android 9;
* iOS 12.}}

== Availability ==
{{key press|Android: Store}}{{key press|iOS: Store}}: Publicly available in Google Play Store / Apple App Store.

{{key press|Android: Store Beta}}: Publicly available in Google Play Store as beta versions. You can opt in or out of the beta at any time in the store.

{{key press|Android: Store Preview}}: Available through Google Play Store's [https://play.google.com/store/apps/details?id=com.augmensys.ubik.go invitation link].

{{key press|iOS: Store Beta}}: Available through Apple App Store's [https://testflight.apple.com/join/Kmb1HG9E invitation link].

{{key press|iOS: Store Preview}}: Available through Apple App Store's [https://testflight.apple.com/join/yHRnbYbt invitation link].

{{key press|Windows: Store Preview}}: The mobile Windows client is not an official product and is only distributed as test versions upon request and/or in our [https://release.augmensys.com/download/modules/client/mobile/ release portal].
<br/>

{{Attention|Some customized XAMLs might need an update to work properly. These changes are marked with a ⚠️}}

= Release Notes =

== Release ==
=== 5.1.?? 2026-??-?? {{key press|Android: Store}}{{key press|iOS: Store}} ===
* Introduced a new [[MRO_Objects_(Client)#Picture_Task|picture task]] type which can only be finished when there's at least one valid child document.
* The system flashlight can now also be enabled or disabled via XAML customization. For detailed information, see [[Mobile XAML#Flashlight|Flashlight]]
* Replaced app closing after repeated failed login attempts with a client-side temporary login block, including user feedback that indicates when login becomes available again.
* Added French localization to the app.
* [[MRO_Objects_(Client)#Signature_Task|MRO Signature Tasks]] have been introduced, which automatically displays the signee as well as the validation timestamp after the task has been signed.
* Fixed an issue where changes in property editing were not discarded when using the default Back button.
* Fixed an issue where the application crashed on Windows when navigating back from the VideoPlayer.
* Icon set Addition 8 adds Show/Hide, AI, Info, and various Procedure icons.
* Fixed an issue where the [[Object_hierarchy_in_XAML:_NextLevel,_ParentLevel,_LinkedLevel#LoadNextLevelCommand|LoadNextLevelCommand]] did not work under specific conditions (invoked in offline and then in online mode).

=== 5.1.30 2026-03-02 {{key press|Android: Store}}{{key press|iOS: Store}} ===
* Fixed an issue that prevented any documents from being uploaded when connecting to 5.1 webservices.

=== 5.1.29 on 2026-02-26 {{key press|Android: Store}}{{key press|iOS: Store}} ===
* Fixed an issue where the POI button was only visible under certain condition (ShowUnreleasedFeatures in the profile is set to true).

=== 5.1.28 on 2026-02-10 {{key press|Android: Store}}{{key press|iOS: Store}} ===
* The following features which existed in pre 5.0 versions are now available again in 5.1.
** [[Map_View|Map view]].
** [[POI_View_(Mobile)|POI view]]. (Aruco and OCR are not yet supported)
** Location service.
** [[Native_Push_(Client)|Native push]].
** [[Charts]].
* UBIK now uses industry-standard JSON Web Token (JWT) technology for authorization, enhancing security and reliability. Session tokens are transmitted via HTTP headers instead of URLs for improved protection.
* Added support for conditionally showing the ImageEditor Save button only when edits have been made, enabled when MergeAnnotationsOnSave is set to true.
* Complete UI overhaul introduces a cleaner, more modern and adaptive user interface with various quality of life improvements.
* UBIKTabView supports both dynamic and static items in combination with lazy loading.
* Files in the app's data folder can now be opened or deleted directly in the developer settings.
* Introduced a fully resource-driven UI theming system enabling fast, safe customization (dark mode, resizing, and consistent styling) by adapting a small set of centralized resources.
* Added support for [[File_Upload_Size_Restriction|configurable file-upload size restrictions]], preventing oversized files from being uploaded and providing users with feedback when limits are exceeded.
* Fixed an issue where annotated image documents do not appear as changed until the UI refreshes.
* Fixed an issue where displayed file content does not update after you revert its changes.
* Fixed an issue where remembered scroll positions were lost when the ItemsSource property of an SfListViewExt changed (e.g., Properties.ShowAllProperties).
* The UI now updates correctly after mass deletion in multi-selection mode.
* Fixed issue that caused app to be stuck on splash screen after resuming from background.
* Fixed an issue where StatusColor was not shown in the UI for objects that didn't additionally have a Progress.
* Fixed an issue where the Chart Thresholds didn't update.
* Fixed an issue that caused content of the custom ContentControl to not be rendered sometimes.
* (Android) Fixed an issue in the WebView where some links could not be opened.
* Fixed an issue where toggling NA in the String Editor did not behave correctly.
* Fixed an issue where the deletion of some objects was not reflected in the UI until refresh.
* Fixed an issue where document creation might not be properly enabled in certain customizing scenarios. For example, a media creation button might be disabled until a page refresh.
* Fixed an issue where batch creating documents (by multi selecting files to attach) can be interrupted if you leave the page.

== Known issues ==
* Due to third-party limitations, the feature that shows the ImageEditor Save button only when edits have been made is only active when MergeAnnotationsOnSave is set to true. In Mobile, deleting the last annotation does not correctly update the editor's internal edit state. As a result, the Save button may remain visible even though no edits exist.
* When changing the device orientation during attaching a photo on iOS, the app gets stuck. This is an issue Microsoft confirmed in .NET9 and will fix in .NET10.
* When editing Guid Link properties, you can no longer further edit the filtering if there are predefined filter parameters (such as the [[Dynamic_Selective_List_(Client)#Dependency_property_values|dependency property values in dynamic selective lists]]). This is because those parameters are to be enforced by design and should not be changed by users. In the future, we might consider a finer level of control over which parameters can be edited in such cases.
* Currently, the Samsung keyboard doesn't show {{key press|,}} at all, regardless of the current language/locale setting of the device. Please use a different virtual keyboard (e.g. Gboard from Google) instead if {{key press|.}} is unacceptable.
* The periodic execution of background pushes is not guaranteed on iOS (the native push feature doesn't have this issue).
* There are still some [[Annotation_and_HotSpot#Known_issues|known issues with free text and text markup annotations]].
* It is currently not possible to select which camera to use for AR views (e.g. scan page) on Windows.
* SfPullToRefresh was removed due to [[Mobile_XAML#Issues_with_SfPullToRefresh_in_Mobile_client|existing issues]], and replaced with a Refresh option in the Context menu.

= ⚠️ XAML Notes =
Due to the change of the underlying XAML technology, the existing XAMLs for the old mobile clients (pre 5.0) are no longer compatible. Please refer to [[HowTo:Convert_Xamarin_XAMLs_to_Maui]] for migrating them to the new client.

<headertabs />

[[Category:Client|Version 5.1 (Mobile)]]
[[Category:Mobile|Version 5.1 (Mobile)]]
[[Category:Version 5.1|Version 5.1 (Mobile)]]

Version 5.1 (WinX)

2026-03-12T13:51:26Z

LGE:

Version 5.1 (Mobile)

2026-03-12T13:50:54Z

LGE:

MRO Objects (Client)

2026-03-12T13:47:16Z

LGE: /* Picture Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} */

[[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)]]
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.

[[File:TechStats_WinX.png|100px|Technical Status Indicator (Winx & Mobile)]]

=== Organisational Status ===
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:UI_WinX_MRO_OrganisationalStatusIndicator.png|Organisational Status Indicator (WinX)
File:ConfirmedWP_WinX.png|MRO Workpackage Confirmed (Flag) Indicator (WinX)
File:Android_orga_status.PNG|Organisational Status Indicator (Android)
File:ConfirmedWP_MAUI.jpeg|MRO Workpackage Confirmed Indicator (Mobile)
</gallery>

=== 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>
File:ConfirmingWP_WinX.png|MRO Workpackage confirm button (WinX)
File:MRORevoke_WinX.png|MRO Workpackage revoke confirmation button (WinX)
File:ConfirmingWP_MAUI.jpeg|MRO Workpackage confirm button (Android)
File:MRORevoke_MAUI.jpeg|MRO Workpackage revoke confirmation button (Android)
</gallery>

=== Task ===
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.

{{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}}

<gallery widths=497px heights=69px>
File:Measurment Task Empty UWP.png|Measurement Task without a reported value (WinX)
File:Measurment Task Not Empty UWP.png|Measurement Task with a reported value (WinX)
File:Measurment Task Empty Android.jpg|Measurement Task without a reported value (Android)
</gallery>

==== Progress Task ====

[[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''.

There is also an [[MRO_PROGRESS_TASK_EDITOR|alternative editor]] available for progress tasks.{{Version/WinXSince|2.5.4}}
{{Clear}}

<gallery widths=497px heights=69px>
File:Progress Task UWP.png|Progress Task with a reported work progress (WinX)
File:Progress Task Android.jpg|Progress Task with a reported work progress and a previous progress(Android)
</gallery>

==== Check Task ====

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.
{{Clear}}

<gallery widths=497px heights=69px>
File:Check Task finished UWP.png|Unfinished MRO CheckTask (WinX)
File:Check Task android.jpg|Not Applicable MRO CheckTask (Android)
</gallery>

==== Inspection Task ====

[[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'''

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.

==== 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.

{{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 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|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.}}

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.

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.

==== 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 tooltip.

* In '''UBIK WinX (UWP)''', hover over the editor field with the mouse.
* In '''UBIK Mobile''', perform a long press on the editor field.
A tooltip will appear, displaying the full User and ValidationTimestamp without truncation.

==== 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.}}

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

=== 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}}

== Locking ==
When an (MRO) object is locked, editing it becomes impossible. More details about [[Locked_Objects|locked objects]].

== See also ==
* [[MRO (Plugin)]]
* [[MROCLS_PROJECT]]
* [[MROCLS_PROJECTINFORMATION]]
* [[MROCLS_SEQUENTIALTASK]]
* [[MROCLS_GROUPEDTASK]]
* [[MROCLS_MRO_CHECK_TASK]]
* [[MROCLS_MRO_INSPECTION_TASK]]
* [[MROCLS_MRO_MEASUREMENT_TASK]]
* [[MROCLS_MRO_PROGRESS_TASK]]
* [[MROCLS_MRO_TASK]]
* [[MROCLS_MRO_TASKOWNER]]
* [[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)

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

MRO Objects (Client)

2026-03-10T16:07:36Z

LGE: /* Picture Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} */

[[File:UI_WinX_MRO_ChildList.png|thumb|alt=MRO Child List UI (WinX)|MRO UI (WinX)]]
[[File:Android_mro_ui.jpg|thumb|alt=MRO Child List UI (Android)|MRO UI (Android)]]
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.

<gallery>
File:UI_WinX_MRO_TechnicalStatusIndicator.png|thumb|Technical Status Indicator (WinX)
File:Android_tech_status.PNG|thumb|Technical Status Indicator (Android)
</gallery>

=== Organisational Status ===
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:UI_WinX_MRO_OrganisationalStatusIndicator.png|Organisational Status Indicator (WinX)
File:UI_WinX_MRO_WPConfirmedIndicator.png|MRO Workpackage Confirmed (Flag) Indicator (WinX)
File:Android_orga_status.PNG|Organisational Status Indicator (Android)
File:Android_orga_status_finished.PNG|MRO Workpackage Confirmed Indicator (Android)
</gallery>

=== 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>
File:UI_WinX_MRO_WPConfirmButton.png|MRO Workpackage confirm button (WinX)
File:UI_WinX_MRO_WPRevokeConfirmButton.png|MRO Workpackage revoke confirmation button (WinX)
File:Android_finish_workpackage.PNG|MRO Workpackage confirm button (Android)
File:Android reopen workpackage.PNG|MRO Workpackage revoke confirmation button (Android)
</gallery>

=== Task ===
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.

{{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}}

<gallery widths=497px heights=69px>
File:Measurment Task Empty UWP.png|Measurement Task without a reported value (WinX)
File:Measurment Task Not Empty UWP.png|Measurement Task with a reported value (WinX)
File:Measurment Task Empty Android.jpg|Measurement Task without a reported value (Android)
</gallery>

==== Progress Task ====

[[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''.

There is also an [[MRO_PROGRESS_TASK_EDITOR|alternative editor]] available for progress tasks.{{Version/WinXSince|2.5.4}}
{{Clear}}

<gallery widths=497px heights=69px>
File:Progress Task UWP.png|Progress Task with a reported work progress (WinX)
File:Progress Task Android.jpg|Progress Task with a reported work progress and a previous progress(Android)
</gallery>

==== Check Task ====

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.
{{Clear}}

<gallery widths=497px heights=69px>
File:Check Task finished UWP.png|Unfinished MRO CheckTask (WinX)
File:Check Task android.jpg|Not Applicable MRO CheckTask (Android)
</gallery>

==== Inspection Task ====

[[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'''

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.

==== 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.

{{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 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|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.}}

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.

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.

==== 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 tooltip.

* In '''UBIK WinX (UWP)''', hover over the editor field with the mouse.
* In '''UBIK Mobile''', perform a long press on the editor field.
A tooltip will appear, displaying the full User and ValidationTimestamp without truncation.

==== Picture Task {{Version/MobileSince|5.1}}{{Version/WinXSince|5.1}} ====

{{UnderConstructionStart}}

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.}}

{{UnderConstructionEnd}}

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

=== 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}}

== Locking ==
When an (MRO) object is locked, editing it becomes impossible. More details about [[Locked_Objects|locked objects]].

== See also ==
* [[MRO (Plugin)]]
* [[MROCLS_PROJECT]]
* [[MROCLS_PROJECTINFORMATION]]
* [[MROCLS_SEQUENTIALTASK]]
* [[MROCLS_GROUPEDTASK]]
* [[MROCLS_MRO_CHECK_TASK]]
* [[MROCLS_MRO_INSPECTION_TASK]]
* [[MROCLS_MRO_MEASUREMENT_TASK]]
* [[MROCLS_MRO_PROGRESS_TASK]]
* [[MROCLS_MRO_TASK]]
* [[MROCLS_MRO_TASKOWNER]]
* [[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)

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

MRO Objects (Client)

2026-03-06T11:47:37Z

2026-02-10T10:14:38Z

LGE:

[[File:UI_WinX_MRO_ChildList.png|thumb|alt=MRO Child List UI (WinX)|MRO UI (WinX)]]
[[File:Android_mro_ui.jpg|thumb|alt=MRO Child List UI (Android)|MRO UI (Android)]]
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 ===
{{UnderConstructionStart}}

The technical status indicates whether all tasks on an object or on its subsequent objects within the underlying data branch have been completed. It also aggregates additional state information, such as issues reported on child items. For example, if an inventory object is marked as damaged, this status is propagated to its parent objects, which will display a corresponding indicator (an exclamation mark) to signal a problem originating from a child item.

{{UnderConstructionEnd}}

<gallery>
File:UI_WinX_MRO_TechnicalStatusIndicator.png|thumb|Technical Status Indicator (WinX)
File:Android_tech_status.PNG|thumb|Technical Status Indicator (Android)
</gallery>

=== Organisational Status ===
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:UI_WinX_MRO_OrganisationalStatusIndicator.png|Organisational Status Indicator (WinX)
File:UI_WinX_MRO_WPConfirmedIndicator.png|MRO Workpackage Confirmed (Flag) Indicator (WinX)
File:Android_orga_status.PNG|Organisational Status Indicator (Android)
File:Android_orga_status_finished.PNG|MRO Workpackage Confirmed Indicator (Android)
</gallery>

=== 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>
File:UI_WinX_MRO_WPConfirmButton.png|MRO Workpackage confirm button (WinX)
File:UI_WinX_MRO_WPRevokeConfirmButton.png|MRO Workpackage revoke confirmation button (WinX)
File:Android_finish_workpackage.PNG|MRO Workpackage confirm button (Android)
File:Android reopen workpackage.PNG|MRO Workpackage revoke confirmation button (Android)
</gallery>

=== Task ===
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.

{{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}}

<gallery widths=497px heights=69px>
File:Measurment Task Empty UWP.png|Measurement Task without a reported value (WinX)
File:Measurment Task Not Empty UWP.png|Measurement Task with a reported value (WinX)
File:Measurment Task Empty Android.jpg|Measurement Task without a reported value (Android)
</gallery>

==== Progress Task ====

[[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''.

There is also an [[MRO_PROGRESS_TASK_EDITOR|alternative editor]] available for progress tasks.{{Version/WinXSince|2.5.4}}
{{Clear}}

<gallery widths=497px heights=69px>
File:Progress Task UWP.png|Progress Task with a reported work progress (WinX)
File:Progress Task Android.jpg|Progress Task with a reported work progress and a previous progress(Android)
</gallery>

==== Check Task ====

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.
{{Clear}}

<gallery widths=497px heights=69px>
File:Check Task finished UWP.png|Unfinished MRO CheckTask (WinX)
File:Check Task android.jpg|Not Applicable MRO CheckTask (Android)
</gallery>

==== Inspection Task ====

[[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'''

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.

==== 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.

{{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 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|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.}}

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.

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.

==== 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.}}

=== 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}}

== Locking ==
When an (MRO) object is locked, editing it becomes impossible. More details about [[Locked_Objects|locked objects]].

== See also ==
* [[MRO (Plugin)]]
* [[MROCLS_PROJECT]]
* [[MROCLS_PROJECTINFORMATION]]
* [[MROCLS_SEQUENTIALTASK]]
* [[MROCLS_GROUPEDTASK]]
* [[MROCLS_MRO_CHECK_TASK]]
* [[MROCLS_MRO_INSPECTION_TASK]]
* [[MROCLS_MRO_MEASUREMENT_TASK]]
* [[MROCLS_MRO_PROGRESS_TASK]]
* [[MROCLS_MRO_TASK]]
* [[MROCLS_MRO_TASKOWNER]]
* [[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)

[[Category:Android|MRO Objects (UBIK WinX)]]
[[Category:Client|MRO Objects (Client)]]
[[Category:Mobile|MRO Objects (Client)]]
[[Category:Pages with broken file links|MRO Objects (Client)]]
[[Category:WinX|MRO Objects (UBIK WinX)]]

Version 5.1 (WinX)

2026-02-10T09:57:56Z

LGE:

Version 5.1 (WinX)

2026-02-10T09:54:21Z

LGE:

List of Versions

2026-02-09T16:35:06Z

2026-01-14T15:06:53Z

LGE:

{{Attention|Existing pre 5.0 XAMLs are not compatible with UBIK Mobile client 5.0. Please refer to [[HowTo:Convert_Xamarin_XAMLs_to_Maui]] for migrating them to the new client.}}

{{Attention|UBIK 5 clients can only connect to {{UBIK}} Servers of [[Version 3.6(Server)|version 3.6]] and higher!}}

{{Attention|The minimum supported OS versions are:
* Android 9;
* iOS 12.}}

== Availability ==
{{key press|Android: Store}}{{key press|iOS: Store}}: Publicly available in Google Play Store / Apple App Store.

{{key press|Android: Store Beta}}: Publicly available in Google Play Store as beta versions. You can opt in or out of the beta at any time in the store.

{{key press|Android: Store Preview}}: Available through Google Play Store's [https://play.google.com/store/apps/details?id=com.augmensys.ubik.go invitation link].

{{key press|iOS: Store Beta}}: Available through Apple App Store's [https://testflight.apple.com/join/Kmb1HG9E invitation link].

{{key press|iOS: Store Preview}}: Available through Apple App Store's [https://testflight.apple.com/join/yHRnbYbt invitation link].

{{key press|Windows: Store Preview}}: The mobile Windows client is not an official product and is only distributed as test versions upon request and/or in our [https://release.augmensys.com/download/modules/client/mobile/ release portal].
<br/>

{{Attention|Some customized XAMLs might need an update to work properly. These changes are marked with a ⚠️}}

= Release Notes =

== Release ==

=== 5.0.223 on 2025-11-17 {{key press|iOS: Store}} ===
* (iOS) Fixed an issue where [[EvalExpression]] doesn't produce expected results for expressions containing "Condition ? A : B".

=== 5.0.221 on 2025-11-05 {{key press|Android: Store}} ===
* (Android) Fixed an issue where creating new objects when there are already a lot of existing ones leads to an app freeze or even crash.

=== 5.0.218 on 2025-10-10 {{key press|Android: Store}}{{key press|iOS: Store}} ===
* Added logging of the authentication headers in UBIKWebserviceDebug.log for better diagnostics.
* A third party issue was fixed where some text Annotations in the ImageEditor weren't visible on iOS.
* A third party issue was fixed where stream bytes increased exponentially when saving Annotations in the ImageEditor.

=== 5.0.212 on 2025-10-03 {{key press|Android: Store}}{{key press|iOS: Store}} ===
* Fixed an issue where task direct editing doesn't work the first time.
* Updated the notification message about branch download to avoid misunderstanding. When a branch download is in progress, you can work with the offline data which is already available at the time of the download, but any communication with the content server will be scheduled after the branch download is finished.

=== 5.0.209 on 2025-09-27 {{key press|Android: Store}} 5.0.207 on 2025-09-25 {{key press|iOS: Store}} ===
* UBIK GO is the cutting-edge evolution of Augmensys' trusted mobile client — rebuilt from the ground up with a modern architecture that unlocks unprecedented flexibility.
* Improved the branch download performance especially when there are duplicate objects in multiple branches.
* Updated some translations.
* Updated the default Demo profile.
* Fixed an issue that triggered a license warning even on a failed login.
* Fixed an issue where the wizard is shown again when you navigate to a new but saved object offline.
* Fixed an issue where duplicate notifications are shown when you scan an NFC tag for a supervisor task and no fitting supervisor is found.

== Known issues ==
* When changing the device orientation during attaching a photo on iOS, the app gets stuck. This is an issue Microsoft confirmed in .NET9 and will fix in .NET10.
* When editing Guid Link properties, you can no longer further edit the filtering if there are predefined filter parameters (such as the [[Dynamic_Selective_List_(Client)#Dependency_property_values|dependency property values in dynamic selective lists]]). This is because those parameters are to be enforced by design and should not be changed by users. In the future, we might consider a finer level of control over which parameters can be edited in such cases.
* Currently, the Samsung keyboard doesn't show {{key press|,}} at all, regardless of the current language/locale setting of the device. Please use a different virtual keyboard (e.g. Gboard from Google) instead if {{key press|.}} is unacceptable.
* The periodic execution of background pushes is not guaranteed on iOS.
* There are still some [[Annotation_and_HotSpot#Known_issues|known issues with free text and text markup annotations]].
* It is currently not possible to select which camera to use for AR views (e.g. scan page) on Windows.
* SfPullToRefresh was removed due to [[Mobile_XAML#Issues_with_SfPullToRefresh_in_Mobile_client|existing issues]], and replaced with a Refresh option in the Context menu.
<br/>

= ⚠️ XAML Notes =
Due to the change of the underlying XAML technology, the existing XAMLs for the old mobile clients (pre 5.0) are no longer compatible. Please refer to [[HowTo:Convert_Xamarin_XAMLs_to_Maui]] for migrating them to the new client.

<headertabs />

[[Category:Client|Version 5.0 (Mobile)]]
[[Category:Mobile|Version 5.0 (Mobile)]]
[[Category:Version 5.0|Version 5.0 (Mobile)]]