Types of Synchronization
Initial sync happens only during the first startup of the plugin. When the plugin is starting-up for the very first time synchronization does not occur, because there are no Boxes in BigPicture/BigGantt yet. At this stage, the parent-child relations have no influence on the synchronization process. Synchronization does not take into account the configuration of the Box, i.e. The Work Breakdown Structure hierarchy (because those things don't exist yet).
All cases of synchronization take into account the following:
- Task modes
- Jira permissions of the user who initialized the change
|Types of Synchronization||When does it occur||Who is the author of a change?|
|Full sync (re-sync)||User actions can trigger a request for data synchronization when a user:|
An Admin user can manually trigger a re-sync of a Box by:
Full sync is in all Boxes after:
|The user who triggers a request for Box data synchronization or the Scope Owner|
|Partial sync (task synchronization)|
Partial sync happens when changes were made:
If there were any changes made by a user in a connected tool (such as Jira or Trello), the events related to these changes are queued inside the app. If there are number of changes applied to the same issue within the interval, the last person who updated the issue will be the author of the last queued change.
When the following Jira events are received:
When the user made any of the following changes in the app:
If a user tries to perform an action for which they have insufficient Jira permissions, they can't do it, so no sync is necessary.
|Author of the change in Jira or in the app.|
Authors of changes
There are three types of users that can be listed as authors of changes:
- Current user (the logged-in person that makes a change; full sync is an exception)
- Scope Owner
- Technical user (in Jira server changes may be listed without any users assigned to a change)
Corrupted Jira index
Full synchronization is not run when BigPicture gets information about the corrupted index from Jira API. A user can perform a Jira re-index; this should solve the corrupted index problem. Users can also continue without reindexing, which can cause irreversible and unintended changes in Box scope.