Plugins: an administrator can hold a plugin or pin it to a version #1264

Open
opened 2026-11-13 10:58:38 +00:00 by tiagoagueda · 0 comments
Owner

The need

An administrator should be able to pin a plugin to a version, or hold it where it is, so that nothing upgrades it automatically (#1187's updates) or by a single click on a bulk "update all". Reasons: the newest release is not yet trusted, it needs a Postulo version this instance has not reached, a bug was found in it, a site has reviewed one version and wants to stay on it, or a downgrade after a bad upgrade.

Wanted

  • Per plugin, an administrator chooses one of: follow the latest (the default), hold at the installed version (no automatic or bulk upgrade; a newer release is still shown, as information, with "held" beside it), or pin to a chosen version from the catalogue's list of releases, installing it now, down- or up-grade, through the same checks as any install (signature, compatibility, SHA-256, snapshot and rollback).
  • Where it lives: a record per plugin on the instance (plugins/models.py), so it survives restarts and upgrades of Postulo; it shows on the plugin's row with who set it and when, and why if they wrote a note.
  • What it blocks and what it does not: automatic updates and "update all" skip a held or pinned plugin. A person with admin rights can still upgrade it by hand, with a confirmation that says it is held. A security release is not applied behind the hold, but the page says one is available for a held plugin, with the advisory, so the hold is never a way to miss it.
  • Postulo upgrades and compatibility: if a held or pinned release does not declare compatibility with the Postulo version being installed, the page says so before the upgrade, and the plugin is shown as incompatible rather than failing at import (as #186 does).
  • Dependencies: a plugin that another plugin requires (requires, #884) cannot be moved to a version the dependant does not accept; say what is blocking it.
  • Config as code: the same setting can be pinned in the environment (POSTULO_PLUGIN_PINS, name==version entries), for people who deploy from a file; an environment pin wins and cannot be changed from the page, as pinned catalogues cannot (#1263).
  • Audit: setting, changing or lifting a hold is written to the audit log with the administrator's name.

Tests

A held plugin is skipped by the automatic and bulk update and still shown with its newer release; a pin installs exactly that version, down- or up-grade, with rollback if it fails; a security release for a held plugin is flagged, not applied; an incompatible pin is refused with the reason; an environment pin cannot be edited on the page; the hold survives a restart and a core upgrade; the audit log has the entry.

Strings go through Weblate only. Related: #1187 (updates), #1263 (the manifest), #884, #186, #1252.

## The need An administrator should be able to **pin a plugin to a version**, or **hold it** where it is, so that nothing upgrades it automatically (#1187's updates) or by a single click on a bulk "update all". Reasons: the newest release is not yet trusted, it needs a Postulo version this instance has not reached, a bug was found in it, a site has reviewed one version and wants to stay on it, or a downgrade after a bad upgrade. ## Wanted - Per plugin, an administrator chooses one of: **follow the latest** (the default), **hold at the installed version** (no automatic or bulk upgrade; a newer release is still shown, as information, with "held" beside it), or **pin to a chosen version** from the catalogue's list of releases, installing it now, down- or up-grade, through the same checks as any install (signature, compatibility, SHA-256, snapshot and rollback). - **Where it lives:** a record per plugin on the instance (`plugins/models.py`), so it survives restarts and upgrades of Postulo; it shows on the plugin's row with who set it and when, and why if they wrote a note. - **What it blocks and what it does not:** automatic updates and "update all" skip a held or pinned plugin. A person with admin rights can still upgrade it by hand, with a confirmation that says it is held. A **security release** is not applied behind the hold, but the page says one is available for a held plugin, with the advisory, so the hold is never a way to miss it. - **Postulo upgrades and compatibility:** if a held or pinned release does not declare compatibility with the Postulo version being installed, the page says so before the upgrade, and the plugin is shown as incompatible rather than failing at import (as #186 does). - **Dependencies:** a plugin that another plugin requires (`requires`, #884) cannot be moved to a version the dependant does not accept; say what is blocking it. - **Config as code:** the same setting can be pinned in the environment (`POSTULO_PLUGIN_PINS`, `name==version` entries), for people who deploy from a file; an environment pin wins and cannot be changed from the page, as pinned catalogues cannot (#1263). - **Audit:** setting, changing or lifting a hold is written to the audit log with the administrator's name. ## Tests A held plugin is skipped by the automatic and bulk update and still shown with its newer release; a pin installs exactly that version, down- or up-grade, with rollback if it fails; a security release for a held plugin is flagged, not applied; an incompatible pin is refused with the reason; an environment pin cannot be edited on the page; the hold survives a restart and a core upgrade; the audit log has the entry. Strings go through Weblate only. Related: #1187 (updates), #1263 (the manifest), #884, #186, #1252.
tiagoagueda added this to the 0.6.0 milestone 2026-11-13 10:58:38 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Postulo/postulo#1264
No description provided.