Optional modules

Some Pluraprint capabilities are optional modules: self-contained subsystems that a deployment either runs or does not. Every module ships in every release, so switching one on needs no upgrade, no separate install, and no downtime. It is a setting, not a deployment.

A module is deliberately coarser than a general setting. Settings adjust how something already running behaves; a module decides whether a whole area of the product exists at all, including its screens, its permissions, the kiosk types it offers, and the background work it does. Turning one off removes all of that together, rather than leaving parts of a feature visible to people who cannot use it.

Open Admin in the sidebar, then choose Modules. Viewing the page requires the Optional Modules: View permission; enabling or disabling a module requires Optional Modules: Update. Someone with view access but not update access sees the real state with the controls disabled.

On or off, for the whole deployment#

A module is one switch for the whole deployment. There is no per-site version of it, and that is deliberate: a module is part of what your deployment is, the permissions it grants, the kiosk types it offers, the events it emits, the sweeps it runs, while a site is a grouping of printers by location or network. Much of what a module does has no site to belong to at all.

Anything that genuinely varies between your sites is site-scoped data rather than a second copy of the module. Pickup is the clearest example: the module is on or off everywhere, and which shelves serve which rooms is decided by assigning each bin to sites.

Reset returns a module to the state the release ships with, rather than freezing it at whatever you last chose. The page tells you which of the two a module is currently following.

The switch takes effect everywhere immediately. Open browsers pick up the new navigation without reloading, and station screens: including unattended ones on a wall that nobody is going to touch: switch to the right screen on their own. There is no restart and nothing to go round and refresh.

What turning one on adds#

Each module says what it introduces, and each is a link to where it appears:

• Settings: the settings group it owns, hidden entirely while it is off. Usually the first place to go after enabling one; a module with a mode to choose does nothing useful until you have chosen it.
• Permissions: new permissions, which nobody holds until you add them to a role. Enabling a module does not give anyone access to it.
• Kinds of station screen: new station types you can assign to a kiosk.
• Events integrations can react to: new event types you can point an email or label-printer integration at.
• Background tasks: periodic work it runs while it is on. These start within the hour, without restarting anything.

Modules that depend on, or exclude, each other#

Two constraints are enforced when you make a change, rather than left for you to remember:

• Requirements. A module that needs another cannot be enabled until that one is, and the module it depends on cannot be switched off while it is still running. The page names what is missing.
• Exclusive groups. Some modules answer the same question in different ways: only one of them may run at a time. Enabling a second one is refused, with the conflicting module named.

Turning a module off#

Disabling a module is never destructive. It hides the module’s screens, stops its background work, and stops it acting on new activity, but nothing already recorded is deleted. Turning the module back on returns you to where you were, including any settings you had chosen.

Because of that, disabling a module that still has work in progress is safe but may be surprising: anything mid-flight stays where it is and stops moving until the module is enabled again. A kiosk configured with one of its station types says so on screen rather than going blank.

Every change is written to the audit log, recording who enabled or disabled which module, and when.