feat(admin): let instances choose which pad types are offered

Add two settings, Protected pads and Public pads, both enabled by default
so existing installations are unaffected. The labels keep the vocabulary
the API and the binding table already use.

Enforcement is server-side, matching allow_external_pads:
PadCreationService covers the API and embed-create paths,
materializeTemplateInto() the templates, and PadBootstrapService guards
its `binding === null` branch -- otherwise an empty .pad plus /initialize
was a way around the setting. The check deliberately stays out of
provisionPadId(), which also re-initialises files that already have a
binding.

Existing pads of a disabled type keep working; only creation is affected.
Turning both off is allowed. A template carrying a disabled mode is
created in the enabled mode rather than failing, and Nextcloud's own
"+ New pad" entry is hidden when protected pads are off, since it always
produces one. External pads stay independent.

The setting decides what the app offers -- it is not a hard boundary
against hand-crafted .pad files. Recovering an orphaned pad from its
snapshot still re-provisions the mode recorded in the file, because
rescuing existing content wins.

Includes de/es/fr translations and doc updates.

Closes #175.

Author: Jaggob

README.md

@@ -95,9 +95,31 @@ and configure:
 - Etherpad API URL (optional; defaults to Base URL)
 - Etherpad API key (OAuth is not required; Etherpad API key auth is used)
 - Copy content to `.pad` file interval
+- Which pad types users may create (see below)
 - Delete-on-trash policy
 - External public pad policy
 
+Two settings control which pad types the app offers, both enabled by default:
+
+- **Protected pads** — only people who can open the `.pad` file in Nextcloud
+  can open the pad. Created as Etherpad group pads, which require a session
+  issued by Nextcloud.
+- **Public pads** — anyone with the pad link can open the pad, without a
+  Nextcloud account.
+
+Switching a type off hides its `+ New` entries and refuses new pads of that
+type on the regular create paths — the API create endpoints, the template
+flows and the first-open initialisation of a `.pad` that has no pad yet. Pads
+that already exist keep working either way.
+
+The setting decides what the app offers; it is not a hard boundary against a
+user who crafts `.pad` files by hand. Recovering an orphaned `.pad` from its
+snapshot still re-provisions the mode recorded in that file, because rescuing
+existing content takes precedence.
+
+Linking external public pads is governed separately by the external pad
+policy and is unaffected by these two settings.
+
 ### 5) Check iframe and cookie setup for protected pads
 
 If protected pads should open inside the Nextcloud viewer iframe:

docs/api-reference.md

@@ -71,6 +71,15 @@ Base: `/apps/etherpad_nextcloud`
     - read-only protected share: `is_readonly_snapshot=true`, empty `url`, `snapshot_text`, and sanitized `snapshot_html`; no Etherpad session cookie
     - public/external pad share: regular public Etherpad URL
 
+Admins can switch either pad type off (see the admin settings). Creating a pad
+of a disabled type is refused with `403` by `POST /pads`,
+`POST /pads/create-by-parent`, `POST /pads/from-template` and the
+`initialize` endpoints; pads that already exist are unaffected. Templates
+carrying a disabled mode are created in the enabled mode instead of failing.
+
+`POST /pads/from-url` is deliberately exempt: external pads are governed
+solely by the separate external-pad policy, not by these two settings.
+
 - `POST /api/v1/pads`
   - Controller: `PadCreateController::create`
   - Params:

docs/architecture.md

@@ -29,6 +29,10 @@ Etherpad is the editing source of truth; the `.pad` file acts as binding storage
   - Revision metadata and snapshot body structure (`[TEXT]`, `[HTML-BEGIN]`, `[HTML-END]`).
 - `lib/Service/PadSessionService.php`
   - Session-cookie flow for protected GroupPads.
+- `lib/Service/PadTypePolicy.php`
+  - Which pad types the instance offers (both enabled by default).
+  - Guards creation only; existing pads of a disabled type keep working.
+  - Resolves a template's access mode to an enabled one instead of failing.
 - `lib/Service/ConsistencyCheckService.php`
   - Optional admin integrity scan:
     - bindings without file
@@ -86,7 +90,7 @@ checked-in runtime assets in `js/`.
 
 ### 1) Create
 
-1. `PadCreateController::create` creates an Etherpad pad (public or protected/group).
+1. `PadCreateController::create` creates an Etherpad pad (public or protected/group). `PadCreationService` asks `PadTypePolicy` first and refuses a pad type the admin switched off; the check sits in the create paths rather than in `PadBootstrapService::provisionPadId`, which also serves existing files.
 2. Creates the `.pad` file.
 3. Writes initial frontmatter.
 4. Creates DB binding.
@@ -249,6 +253,7 @@ Primary flow (native viewer when available):
   - `+ Neu` integration for `Public pad` with runtime capability checks:
     - modern API: `addNewFileMenuEntry` / `getNewFileMenu().registerEntry`
     - legacy API fallback: `OC.Plugins.register('OCA.Files.NewFileMenu', ...)`
+  - The `Public pad` entry follows the admin setting, read from initial state. `Public pad from URL` is always registered; the external-pad policy is enforced server-side when the create call arrives.
 - `src/files/public-share-pad-links.js`
   - Public-share click interception for download links that need remapping to the pad viewer.
   - Authenticated Files routes intentionally do not use global click interception.

docs/etherpad-integration.md

@@ -37,6 +37,10 @@ Important:
   - GroupPad ID (`g.<group>$<name>`).
   - Access only with a valid Etherpad session (`sessionID` cookie).
 
+Either type can be switched off in the admin settings, which stops new pads of
+that type from being created. Existing pads keep opening regardless, so the
+setting never cuts anyone off from content.
+
 ## Session Flow (protected)
 
 Implemented in `lib/Service/PadSessionService.php`.

docs/templates.md

@@ -80,6 +80,7 @@ Response shape on success (200):
 
 Error responses:
 - **400** — template is not a `.pad`, template is external (`ext.*`), template is empty, target path invalid
+- **403** — no pad type is enabled in the admin settings, so nothing can be created
 - **404** — template file ID does not resolve in the user's userspace
 - **409** — target filename collides with an existing file (`A file with this name already exists.`)
 - **500** — Etherpad unreachable or other unexpected failure
@@ -90,3 +91,4 @@ Error responses:
 - **Failed template materialisation falls back to a blank pad.** If anything in the listener throws (binding race, Etherpad unreachable, malformed template), the byte-copy NC made is wiped and the new file behaves like a normal empty `.pad` — the regular missing-frontmatter init kicks in on first open.
 - **Placeholder substitution applies to both the plain-text and the HTML snapshot in the body**. If a placeholder ends up inside an HTML attribute (`<a href="{{date}}">`), it gets resolved too — keep placeholders in human-readable locations to avoid surprises.
 - **No template registry** — every `.pad` in the user's *Templates* folder is a candidate. There's no separate "is a template" flag.
+- **A template keeps its own access mode**, unless the admin switched that pad type off. In that case the pad is created in the enabled mode instead of failing, so the template's content still lands. With no pad type enabled at all, template creation is refused.