Lifecycle of a Job

The 1Spatial Management Suite provides the following lifecycle for a job:

1. A job is allocated by a planner to the user or to a group of users according to the organisation.

2. A job is selected for work and is activated by a single user.

   Note: A job can only be activated and worked on by a single user.

3. When a job has been activated, the work package is automatically prepared by the server. This task may take a variable amount of time depending on the size of the job.

4. The work package is downloaded to the local machine. This package includes all the spatial data that can be edited in performing the job, along with some surrounding data for context. It also can include imagery data and other resources to assist in performing the work.

5. The job can then be opened in 1Edit, which turns the downloaded data into a 1Edit project, and opens the project.

6. Once the user has finished the work, they can close the project, return to the worklist where the job can be uploaded. They are prompted to add comments and specify the time spent on the job. Changes are then uploaded to the server.

7. The changes are then validated:

   • If the job fails validation, the job is marked as invalid and a child job is created to correct the validation error.

     This child job goes through the same lifecycle as a normal job, and once it has been corrected and passes validation, the parent job continues its lifecycle (see Server-side Validation).

   • If the job passes validation, it continues its lifecycle.

8. If a job is marked for quarantine, then the job is put into quarantined state and a quarantine review job is created and allocated to the user or group that the 1SMS administrator has configured to perform the review, who can then accept, send comments or discard the job. See Quarantine Lifecycle for details on this optional stage.

9. Conflict checks are performed to see if any other user has edited the same features as those edited by the current job.

   If any conflicts are found that are not automatically resolvable then the job is put into a conflicted state and a conflict resolution job is created in which the conflicts can be resolved.

10. The job is completed.

    Note: Jobs will be no longer visible in the worklist after they have been completed for more than 24 hours.

Quarantine Lifecycle

Optionally, a planner can decide that a job will need to be quarantined. This requires a job to be checked before completion, and stops the changes being immediately applied to the central database once validated.

Note: A job must be marked for quarantine before it is allocated, and the job will not appear any differently to the user or group to whom it is assigned.

If quarantined, a job will have additional steps in its lifecycle. Once it passes validation, it moves to a Quarantined status (rather than Completed) and a child "review" job is created for the changes to be checked by another user (a "reviewer").

The reviewer looks at the edits made by the editor, and selects one of three quarantine results:

Quarantine Result	Reviewer's reaction	Actions taken
Approved	No fault with the data.	The child review job is completed, with a status of "Approved". The parent job continues its lifecycle and is checked for conflicts before being merged with the live data and completed.
Corrections Required	Small changes are required.	The reviewer provides feedback and makes changes to the map data as required. The child review job is completed, with a status of "Corrections Required". A second child "correction" job is created, including both the original edits made by the editor and any new edits by the reviewer. This correction job has a state of "Allocated", ready to be downloaded and worked on by the editor. The editor makes the corrections and uploads changes. Once this child job validates, the edits are merged into the parent job, and the child correction job is completed. The parent job is re-validated, and passes back into Quarantine for re-review.
Rejected	The data is incorrect and the work needs to be repeated.	The child review job is completed, with a status of "Rejected". The parent job is moved back to the Downloaded state to be repeated or relinquished. Note: A rejected job still retains all edits made. In order to discard these edits, the job must be relinquished and then re-activated.

Note: Once a job passes quarantine, it will be checked for conflicts like any other job. However, because conflicts are only detected relative to the parent job then conflicts with other users edits in the live version of the data will only be detected when the original job is completed. This means depending on how the administrator has configured conflict resolution, this might mean that the original worker is presented with the conflicts caused by the quarantine reviewer's edits.