The Prearchive is constantly listening for incoming sessions, and is very sensitive to the status of a given session. As such, it makes sense to restrict what actions a user can perform on a given session (or group of sessions) based on its status.
Here is a list of statuses and actions, cross-referenced for easy reference. It should be noted that bulk actions are processed asynchronously, so there is an fine distinction between "Delete Pending" and "Deleting Now,"
|Action / Status||Archive||Review and Archive*||Change Project||Delete||Rebuild (was "Reset")||Cancel****|
|(UNASSIGNED) ***||No||No||Yes (by Admin only)||Yes (by Admin only)||Yes (by Admin only)||No|
|"Pending" Statuses - Action has been selected and is queued for processing|
|ARCHIVE PENDING||No||No||No||No||No ||Yes|
|BUILD PENDING||No||No||No||No ||No ||Yes|
|MOVE PENDING||No||No||No||No ||No ||Yes|
|"Locked" Statuses - Action is currently in process|
|ARCHIVING NOW||No||No||No||No||No ||No|
|BUILDING NOW||No||No||No||No||No ||No|
|DELETING NOW||No||No||No||No||No ||No|
|MOVING NOW||No||No||No||No||No ||No|
* Review and Archive
** The conflict status reflects a session in the Prearchive that has the same name and project as an existing session in the archive.
*** Unassigned sessions do not appear in the UI for non-Admin users. These sessions have malformed headers caused by improper data entry at the scanner.
**** There is REST support for an "Undo" or "Cancel" action, but no reflection of this in the UI. This may not appear until XNAT 2.0.
Items marked with indicates an open question for XNAT developers.
- Items in a Pending state should not have any other actions allowed, other than an "Undo" function. However, there is not support for this in the UI yet.
- Items in a Locked state should not have any actions allowed, period.
Actions Logic Flow