Data retention

Every print job Pluraprint stores keeps its design file and thumbnail in object storage for as long as the job exists. Over years of operation that adds up: design files are the largest objects the platform holds, and a job finished three years ago is rarely worth the space it occupies.

Data retention is an optional policy that deletes finished print jobs once they pass an age you choose, along with the files they referenced.

Turning it on#

Open Admin > Settings and find the Data retention section. You need the General Settings: Update permission.

• Delete old print jobs turns the policy on. It is off by default, and stays off until you turn it on: upgrading Pluraprint never starts deleting anything.
• Delete jobs after sets the deadline, in days. The default is 365 days and the minimum is 14.

Changes take effect on the next sweep, which runs every six hours.

What gets deleted#

When a job passes the deadline, Pluraprint deletes:

• the print job itself, and everything attached to it: its event history, material requirements and recorded usage, approval decisions, and the requirement results shown on its detail page;
• its design file and thumbnail, once no other job still uses them (see below);
• any snapshots captured for that job.

The job disappears from history for everyone, including from Print Management > History.

What is never deleted#

• Jobs that haven’t finished. Only jobs that are Completed, Failed, Cancelled, or Rejected are eligible. A queued, printing, or awaiting-approval job is never deleted no matter how old it is, and neither is the job a printer currently has loaded.
• The audit log. Audit entries are append-only and are kept in full, including entries about jobs that no longer exist. Compliance reporting and the tamper-evidence chain are unaffected.
• Aggregate analytics. Figures derived from the audit trail keep their history.

How the deadline is measured#

The clock runs from the last time anything happened to the job: not from when it was submitted. A job that was completed and then had a snapshot or a status change recorded against it is measured from that later moment.

Reprints#

Reprints share the original’s design file rather than making a second copy of it, so several jobs commonly point at one stored file. Retention accounts for this:

• A file is only deleted once no job still refers to it. When an old job expires but a reprint of it is still around, the job is deleted and the file is kept. The file goes when the last job referencing it expires too.
• Reprinting refreshes the file’s lifespan. The reprint is a new job with a new clock, so an active design keeps its file for as long as people keep reprinting it.
• A job past the deadline cannot be reprinted. The Reprint button reports that the job has passed the retention deadline. Upload the file again to print it.

If you rely on reprinting old jobs, set the deadline longer than the longest gap you expect between reprints.

Working through a backlog#

The first sweep after enabling retention on a long history has a lot to do. It works in bounded batches and picks up where it left off on the next run, so a large backlog clears over several sweeps rather than in one long operation. Nothing else slows down while it does.

Local disk is managed separately#

Retention governs the object store: the permanent copy of every file. The temporary copies that the API, the task workers, and each site agent download while they work are managed independently and automatically. They are removed as soon as the work using them finishes, and any that linger are reclaimed on a schedule. No configuration is required, and no setting here affects them.