Bulk device jobs
Devices → Bulk location updates queues the same room/location value for up to
500 known serial numbers. All serials must resolve within the creator’s current
campus access; an unmatched or inaccessible serial refuses the whole submission.
Duplicate serials are collapsed. Creating jobs requires device.manage and the
Assets module. Each job is visible only to its creator, and its target results
are filtered again by current campus access.
The first supported operation updates Plugboard’s location field and records
manual ownership so MDM sync does not undo it. It does not change the campus
access boundary or send a command to devices. The API accepts the defined
device.setLocation operation, a location and serial numbers; arbitrary connector
capabilities, URLs, scripts and credentials are not job inputs.
A database sweep runs every five seconds with at most fifty targets per tenant per sweep and four concurrent transactions. Ten open jobs per tenant and three creation requests per minute bound queue growth. Before each target, it rechecks that the creator is active, still holds device management permission, and can access that device within both the original and current campus scope.
The target effect, manual field provenance, audit row and result commit in the same transaction. A job lock serialises concurrent workers and cancellation. Restarting a process cannot leave a committed location update without its result. Transient database failures use exponential backoff and stop after three attempts; permission or input refusals fail immediately. The creator can retry eligible failed targets, up to six attempts in total, or cancel pending targets. Cancellation does not undo completed updates. A completed job can contain failures; the results view shows them explicitly and supports filtering by target status.
BulkJob stores the owner, operation, input, original scope and overall status.
BulkJobTarget stores the device relation, status, attempts, next retry time,
sanitised error and result. Both are tenant-scoped with RLS; targets also use the
device’s site filter. No connector response or identity-provider data is stored.
This is the reusable parent/target primitive for local transactional operations. Adding a remote fan-out operation requires its own reviewed authorisation and idempotency contract, durable claim/lease, and an uncertain-outcome state. A remote write must not inherit local transaction retry semantics. Jobs currently remain until tenant deletion; device deletion removes its target rows. A future retention policy should preserve the separately retained audit evidence.