Rules & Quotas Overview

Pluraprint gives administrators two complementary tools for controlling how print jobs flow through your organization: rules and quotas. Together they let you answer questions like:

• “Does every print job need someone to approve it before it queues?”
• “Can students print without staff sign-off if the job is small enough?”
• “How much filament can each person use per month?”
• “Should certain file types or printers be off-limits after hours?”

Both are managed under the Admin section of the sidebar, by users with the appropriate permissions (see Roles & Permissions).

Rules: building a job’s checklist#

Every print job has a requirements checklist: a list of things that must be true before the job can be queued for printing. Pluraprint builds this checklist automatically by checking every enabled rule against the job:

• A rule has a condition (“when does this rule apply?”) and one or more requirements (“what must be true if it does?”).
• If a rule’s condition matches a job, all of its requirements are added to that job’s checklist.
• Every matching rule contributes: there’s no “first match wins”. A job’s final checklist is the combination of requirements from every rule that applies to it.

This means you can build up policy from small, focused rules, for example, one rule that requires approval for large jobs, and a separate rule that requires approval for after-hours submissions. A job submitted at midnight that’s also large will pick up requirements from both.

Checklist statuses#

Each item on a job’s checklist is shown to the submitter and to staff with one of three statuses:

Status	Meaning
✅ Satisfied	This requirement has been met.
🟡 Needed	Still to do. The control for doing it is on the same screen.
🔴 Missing	Needed, and skipped when you tried to submit.
🔴 Blocked	Ruled out by what’s already known: over a limit, a “deny” rule, an approver who isn’t eligible. Nothing you enter next will change it.
🟡 Pending	Waiting on information before Pluraprint can judge it.
❓ May apply	Pluraprint can’t yet tell whether the rule behind this item applies.

Needed and Missing are one item in two presentations. A checklist stays calm while you fill a job in and only turns red where you skipped something, the same way any other form behaves, so a checklist item is never an accusation that you haven’t got to something yet.

A checklist also leaves out what the screen already tells you: an item that is merely Needed, and whose rule has no Message to user, isn’t listed above the very control that satisfies it.

A job only becomes eligible to queue once every item on its checklist is satisfied. See Key Concepts for how this fits into the overall print job lifecycle, and Building Rules for how to create rules that produce these requirements.

Rules that depend on something Pluraprint doesn’t know yet#

A rule can only be judged against what Pluraprint currently knows about a job. A rule that asks about the job owner’s role, for example, cannot be decided at all until the owner has signed in or tapped their card: at a station, that is usually after the file has been uploaded. Such a rule is neither matched nor unmatched; it is undecided.

Pluraprint never guesses in either direction:

• It does not assume the rule matches. A “may apply” checklist item is shown, but it does not demand an approver, count towards a job’s approval stages, offer an “approve” or “request approval” button, or repeat the rule’s Message to user. That message explains why a rule applied, so showing it here would tell every unidentified person that a rule about, say, suspended accounts had matched them.
• It does not assume the rule doesn’t match either, which would let exactly the people a restriction targets slip past it by not identifying.

Instead, the job is routed to whatever would settle the question. The checklist item says what it is waiting on (“Staff approval may be required. Waiting on the job owner’s role.”), and the job’s status becomes Waiting for you to identify until the owner is known. Once they are, the rule is decided the ordinary way. It either applies in full, with its message, or it vanishes from the checklist.

The checklist is evaluated live while a user or station prepares the job, so required fields appear and disappear with the current context. The browser and station use the same shared evaluator for immediate feedback. The server independently evaluates the current rules again before queueing; client-side results are never trusted as authorization or proof of satisfaction.

Quotas: enforcing usage limits#

While rules decide what a job needs before it can queue, quotas decide how much any person, role, station, or site can print over time: independent of any specific job’s requirements.

A quota might say things like:

• “Each user can have at most 1,000g of filament queued or printing per month.”
• “No more than 3 jobs may be actively printing at once, fleet-wide.”
• “The Engineering role gets a higher monthly print-time allowance than Members.”

When a job would push a subject over a quota’s limit, Pluraprint blocks (or warns about) the job depending on the quota’s severity. See Setting Usage Quotas for details on configuring these.

Automation: acting without being asked#

Rules and quotas both answer a question about something a person is trying to do. A third system, automation rules, answers a different one: what should Pluraprint do unprompted when something becomes true: such as notifying someone about a print that failed, or restricting somebody who has left four prints uncollected.

Automation rules reuse the same condition builder, and are also evaluated as a set rather than first-match. What they add is that each effect applies to a given subject once, ever, that effects touching someone’s access wait for a person to confirm them, and that every action is recorded and reversible. See Automation Rules.

Print restrictions: stopping one person for a while#

Rules and quotas both ask something about a job. A print restriction is about a person: it stops their jobs going ahead for a set period, with a reason they can read and a date it ends, and it remembers how many times this has happened so a repeat can cost more than the first time.

Restrictions are what to reach for instead of a “Banned” role. A role says what someone is allowed to do and has no reason, no end date, and no memory; a restriction has all three and expires by itself. See Print Restrictions.

How these work together#

Rules, quotas, and restrictions are independent systems that all run when a job is submitted or queued:

• Rules determine the checklist of conditions a job must satisfy: things like approvals, identification, or outright denial based on file type, time of day, and so on.
• Quotas independently check whether allowing this job would exceed a usage limit for its owner, role, station, or site.
• Print restrictions check whether the job’s owner is currently stopped from printing at all.

A job can be held up by any of them: an unsatisfied rule requirement (shown on the job’s checklist), a quota limit (shown as a quota warning/block), or an active restriction (shown on the checklist with the reason, and with an override control for staff where the policy allows one). All are visible to the job’s owner and to staff reviewing the queue.

Where to go next#

• Building Rules: create and manage rules, conditions, and requirements.
• Setting Usage Quotas: create and manage usage quotas and view usage dashboards.
• Automation Rules: have Pluraprint act on its own when something becomes true.
• Print Restrictions: stop someone printing for a while, and decide what happens the next time.