The Sync Manager collects all synchronization operations of the UBIK® client that could not be completed successfully and offers a central place to review, retry, report or dismiss them. In addition, it lists all local changes that have not been committed to the server yet.
It replaces the former behavior where failed synchronizations were either not visible at all or interrupted the user. Failed operations are now recorded silently in the background, and the user can decide when and how to deal with them.
 | Only failed operations are listed. As soon as an operation succeeds (e.g. through a retry or a later automatic synchronization), the corresponding entry disappears from the list automatically. |
Opening the Sync Manager
The Sync Manager is opened via buttons which are only shown if there is something to handle:
| Button | Shown when | Opens tab |
|---|---|---|
| Sync issues (alert icon + number of issues) | at least one synchronization issue exists | Needs attention |
| Uncommitted changes (unsaved-changes icon + number of objects) | at least one object has local changes that are not committed yet | Uncommitted changes |
- WinX: The buttons are located on the right side of the global status bar (visible after login).
- Mobile: The buttons are located in the bottom row of the menu area.
 | The Sync Manager does not open automatically when a synchronization fails. Keep an eye on the sync issues indicator. |
Tabs
Issues are grouped by how urgently they require the user's attention. The number in front of each tab title shows the number of entries in that tab.
| Tab | Content | Typical impact |
|---|---|---|
| Needs attention |
|
Local work has not reached the server, or offline data is incomplete. Should be handled as soon as possible. |
| Review |
|
Displayed data might be outdated or incomplete. |
| Background |
|
Background operations which usually recover by themselves. |
| All issues | All entries of the three tabs above. | |
| Uncommitted changes | Objects with local changes that are not committed to the server yet. | See Uncommitted Changes. |
Each entry has a colored marker on its left side: red for Needs attention types, orange for Review types and grey for Background types.
Sync Issue Entries
Every entry shows:
- a summary consisting of the operation and the affected object (name and description),
- the location of the affected object in the hierarchy,
- the time when the operation failed (most recent failure),
- the report state: Not reported, ✓ Reported or ⊗ Report failed.
When expanding an entry, the following details are displayed:
- Sync type – the kind of operation (e.g. BranchHierarchyDownload, CommitChanges)
- Web service call – technical information about the failed server call (URL, status code, duration, error details). Session tokens are not included.
- Location – the full path(s) of the affected object(s)
- Error – the error message
Failed documents of a branch download
If documents fail to download during a branch download, the branch is listed in Needs attention and the failed documents are shown nested inside the branch entry (visible when expanded). Documents which are downloaded individually (e.g. by opening a document) are listed as separate entries in the Review tab instead. If a failed Document download under a branch download is retried and fails again, then it is also displayed in the Review section as a single file Document download.
Repeated failures
If the same operation (same type, same object(s)) fails again, no additional entry is created. The existing entry is updated with the new time, error and web service call instead, and its report state is reset to Not reported.
Actions
Actions can be executed for a single entry (buttons on the entry) or for several selected entries at once (bulk buttons).
| This only works in Online and Manual Sync mode. |
| Action | Description | Requires online mode |
|---|---|---|
| Retry | Executes the failed operation again. If it succeeds, the entry is removed. If it fails again, the entry is updated. Retrying a branch download downloads the branch again, including its documents. When several failed commits are retried together, all affected objects are committed in one single commit. | yes |
| Report | Sends the selected entries, including their technical details, to the UBIK® server so that administrators can analyze the problem. The report state of the entries changes to ✓ Reported or ⊗ Report failed. Reporting does not remove the entry. | yes |
| Remove | Removes the entry from the list without retrying the operation. Removing a branch download also removes its nested failed documents. | no |
| Remove only dismisses the entry – it does not undo or repeat anything. For example, removing a failed commit entry does not discard the local changes; the object stays in the Uncommitted changes tab. |
Selecting multiple entries
- WinX: Hover over the list and click the selection icon at the top to switch to multi-selection. A toolbar with Select all, Deselect all, Retry Selected, Report Selected and Remove Selected appears. The buttons on single entries are shown when hovering over an entry.
- Mobile: Entries can be selected by tapping them or via their checkbox. The toolbar with Select all, Deselect all, Retry Selected, Report Selected and Remove Selected is always visible.
The All issues tab shows the same entries as the other tabs, so a selection made in one tab is also visible in All issues.
Offline mode
While the client is in offline mode, Retry, Report and Commit are disabled and a corresponding hint is shown. Entries can still be viewed and removed. No new sync issues are recorded in offline mode because no synchronization is attempted.
Automatic Merging
tbd
Uncommitted Changes
The Uncommitted changes tab lists all objects which were changed, created or deleted locally but not yet committed to the server. Select one or more objects and use Commit to upload the changes. Committing requires online or manual mode. If the commit fails, a corresponding entry is added to the Needs attention tab.
Persistence
Sync issues are stored in the local client database. They are therefore
- kept after restarting the client,
- stored separately per user and per profile,
- loaded after login.
They are deleted when the issue is resolved (successful retry or synchronization), when the user removes them, or when the affected object is deleted.
Reporting (Server)
Issues can be reported to make Admins aware they exist and can react accordingly. Reported issues are sent to the content service (service version 530 -> add flag!) and stored there as well. The server does not send these reported issues back; you only receive OK or failed as a response.
See also
