feat(settings): enable Pad-wide Settings by default; fix misleading modal title by JohnMcLear · Pull Request #7679 · ether/etherpad

JohnMcLear · 2026-05-05T16:57:48Z

Summary

Flip the default of enablePadWideSettings from false to true in src/node/utils/Settings.ts and both shipped settings files (settings.json.template, settings.json.docker). The creator-owned pad-wide settings feature (Add creator-owned pad settings defaults #7545) is now on out of the box.
Drop the conditional <h1> in src/templates/pad.html and always use pad.settings.title ("Settings"). With the feature off, the H1 was rendering pad.settings.padSettings ("Pad-wide Settings") for everyone — a label that lied about a section that wasn't rendered.
Adds backend regression coverage in src/tests/backend/specs/socketio.ts for the creator gate (different cookie jars vs. shared cookie jar / same authorID).

Why this is a behavior change worth taking

Reproducing on a default install: open /p/foo in two different browsers. Both see the modal heading "Pad-wide Settings", even though there are no pad-wide controls in the body. That looked like a creator-gate regression but turned out to be the H1 copy bug above.
The intended design of Add creator-owned pad settings defaults #7545 is: the original creator (isPadCreator = authorId === pad.getRevisionAuthor(0)) gets a "Pad-wide Settings" section to set defaults / optionally enforce them, while everyone else sees only "User Settings" (their personal view). That's the better default UX, and is what most operators will expect on a fresh install.
The flag is preserved — operators who want the legacy single-section modal can set enablePadWideSettings: false. The settings comments are expanded to describe what the toggle now does.

Server-side gate is unchanged

canEditPadSettings is still computed by:

const canEditPadSettings = settings.enablePadWideSettings &&
    !sessionInfo.readonly && await isPadCreator(pad, sessionInfo.author);

Non-creator clients still receive canEditPadSettings: false, and pad_editor.ts:235 still gates the unhide on it. Flipping the default does not widen who can edit pad-wide settings.

Test plan

tests/backend/specs/socketio.ts — new Pad-wide settings creator gate describe block:
- Different browsers / cookie jars → only the first joiner is the creator (canEditPadSettings: true); the second is not (false).
- Same browser two tabs / shared cookie → BOTH connections are the same authorID, both correctly land on the creator path.
Full backend specs (952 pass; the 6 favicon/robots failures are pre-existing on develop, unrelated)
Manual on a default install: open /p/foo from two different browsers — only the first sees "Pad-wide Settings"; the second sees only "User Settings".
Manual with enablePadWideSettings: false — modal H1 reads "Settings", body still has the legacy "My View" section.

Reviewer notes

This is a default flip (not a code-path change), so existing operators who rely on the legacy single-modal layout need to set enablePadWideSettings: false after upgrade. Worth highlighting in release notes.

…odal title The creator-owned Pad-wide Settings feature (#7545) shipped behind a flag that defaulted to false. With the flag off the modal still rendered an H1 of `pad.settings.padSettings` ("Pad-wide Settings") for *every* user, even though no pad-wide controls were ever shown. Two readers in different browsers both saw "Pad-wide Settings" as the modal title, which looked like a creator-gate regression but was just a copy bug. Two changes: 1. Flip the default of `enablePadWideSettings` to `true` (Settings.ts plus both settings templates). With the feature on, the creator (revision-0 author) gets a real "Pad-wide Settings" section gated by `clientVars.canEditPadSettings`, while every other user sees only "User Settings" — matching the design intent of #7545. This is a behavior change, so the settings comments are expanded to describe what the toggle now does. 2. Drop the conditional H1 in `src/templates/pad.html` and always use `pad.settings.title` ("Settings"). Operators who explicitly disable the feature shouldn't see a label that lies about a section that isn't rendered. Adds backend regression coverage in `tests/backend/specs/socketio.ts`: - Different browsers (different cookie jars => different authorIDs): only the first joiner gets `canEditPadSettings: true`. - Same browser, two tabs (shared HttpOnly token cookie => same authorID): both connections are the same identity, both correctly land on the creator path.

qodo-code-review · 2026-05-05T16:57:53Z

ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one.

qodo-free-for-open-source-projects · 2026-05-05T16:58:06Z

Review Summary by Qodo

Enable Pad-wide Settings by default and fix modal title

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Enable Pad-wide Settings by default for better UX
• Fix misleading modal title that showed "Pad-wide Settings" for all users
• Add backend regression tests for creator gate logic
• Expand settings documentation to clarify feature behavior

Diagram

flowchart LR
  A["enablePadWideSettings: false"] -->|Flip default| B["enablePadWideSettings: true"]
  B -->|Creator sees| C["Pad-wide Settings section"]
  B -->|Others see| D["User Settings only"]
  E["Conditional H1 logic"] -->|Remove| F["Always use Settings title"]
  G["No creator gate tests"] -->|Add| H["Creator gate regression tests"]

File Changes

1. src/node/utils/Settings.ts ⚙️ Configuration changes +1/-1

Flip enablePadWideSettings default to true
• Changed enablePadWideSettings default from false to true
• Enables creator-owned Pad-wide Settings feature on fresh installs
src/node/utils/Settings.ts

2. src/templates/pad.html 🐞 Bug fix +0/-4

Remove conditional modal title logic

• Removed conditional H1 rendering based on enablePadWideSettings
• Always render H1 with pad.settings.title ("Settings")
• Fixes misleading modal title that appeared for all users regardless of feature flag

src/templates/pad.html

3. settings.json.template ⚙️ Configuration changes +5/-2

Enable Pad-wide Settings and improve documentation

• Changed enablePadWideSettings default from false to true
• Expanded documentation to explain creator-only Pad-wide Settings section
• Clarified that non-creators see only User Settings
• Added note about reverting to legacy behavior if needed

settings.json.template

View more (2)

4. settings.json.docker ⚙️ Configuration changes +5/-2

Enable Pad-wide Settings and improve documentation

• Changed enablePadWideSettings default from false to true
• Expanded documentation to explain creator-only Pad-wide Settings section
• Clarified that non-creators see only User Settings
• Added note about reverting to legacy behavior if needed

settings.json.docker

5. src/tests/backend/specs/socketio.ts 🧪 Tests +61/-1

Add creator gate regression tests

• Added enablePadWideSettings to settings backup/restore list
• Added new test suite "Pad-wide settings creator gate" with two test cases
• Test 1: Different browsers get different canEditPadSettings values (creator vs non-creator)
• Test 2: Same browser/cookie jar results in both connections being creator

src/tests/backend/specs/socketio.ts

qodo-free-for-open-source-projects · 2026-05-05T16:58:08Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (2)

1. enablePadWideSettings default enabled 📘 Rule violation ☼ Reliability

Description

The PR flips enablePadWideSettings to default to true, enabling the feature without explicit
operator opt-in. This violates the requirement that new/flagged functionality be disabled by default
and can also change behavior for deployments with older configs that omit this key.

Code

src/node/utils/Settings.ts[372]
+  enablePadWideSettings: true,

Evidence
PR Compliance ID 5 requires feature-flagged functionality to be disabled by default, but the PR
changes the default value to true in code and both shipped config templates. This also impacts
backward compatibility expectations for older configs that relied on the previous default (PR
Compliance ID 3).
src/node/utils/Settings.ts[372-372]
settings.json.template[741-741]
settings.json.docker[255-255]
Best Practice: Repository guidelines
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`enablePadWideSettings` is now enabled by default (`true`) in runtime defaults and shipped config templates, which violates the requirement that feature-flagged functionality be disabled by default and may change behavior for installs that do not set this config key.

## Issue Context
The PR flips defaults in:
- runtime defaults (`src/node/utils/Settings.ts`)
- `settings.json.template`
- `settings.json.docker`

## Fix Focus Areas
- src/node/utils/Settings.ts[370-373]
- settings.json.template[733-741]
- settings.json.docker[247-255]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. No test for modal H1 📘 Rule violation ☼ Reliability

Description

The PR fixes the settings modal heading logic by removing the conditional title, but it does not add
a regression test that would fail if the old misleading heading behavior returned. This makes the UI
bug fix unverifiable and prone to regression.

Code

src/templates/pad.html[R129-131]

      <div id="settings" class="popup" role="dialog" aria-modal="true" aria-labelledby="settings-title"><div class="popup-content">
-          <% if (settings.enablePadWideSettings) { %>
          <h1 id="settings-title" data-l10n-id="pad.settings.title">Settings</h1>
-          <% } else { %>
-          <h1 id="settings-title" data-l10n-id="pad.settings.padSettings">Pad Settings</h1>
-          <% } %>
          <div class="settings-sections">

Evidence
PR Compliance ID 1 requires a regression test for bug fixes; the PR changes the settings modal
heading in src/templates/pad.html but the only added tests in this PR cover the backend creator
gate (canEditPadSettings), not the modal title behavior.
src/templates/pad.html[129-131]
src/tests/backend/specs/socketio.ts[327-385]
Best Practice: Repository guidelines

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The settings modal heading bug fix (always using `pad.settings.title` / `Settings`) has no automated regression coverage.

## Issue Context
This PR changes the modal `<h1 id="settings-title">` rendering logic in `src/templates/pad.html`, but does not add a test that asserts the heading text/label under the relevant configuration states.

## Fix Focus Areas
- src/templates/pad.html[129-138]
- src/tests/frontend-new/specs/pad_settings.spec.ts[1-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-free-for-open-source-projects · 2026-05-05T17:00:52Z

  updateServer: "https://static.etherpad.org",
  enableDarkMode: true,
-  enablePadWideSettings: false,
+  enablePadWideSettings: true,


1. enablepadwidesettings default enabled 📘 Rule violation ☼ Reliability

The PR flips enablePadWideSettings to default to true, enabling the feature without explicit operator opt-in. This violates the requirement that new/flagged functionality be disabled by default and can also change behavior for deployments with older configs that omit this key.

Agent Prompt

## Issue description `enablePadWideSettings` is now enabled by default (`true`) in runtime defaults and shipped config templates, which violates the requirement that feature-flagged functionality be disabled by default and may change behavior for installs that do not set this config key. ## Issue Context The PR flips defaults in: - runtime defaults (`src/node/utils/Settings.ts`) - `settings.json.template` - `settings.json.docker` ## Fix Focus Areas - src/node/utils/Settings.ts[370-373] - settings.json.template[733-741] - settings.json.docker[247-255]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Intentional. The maintainer (@JohnMcLear) explicitly approved flipping this default in conversation prior to opening the PR — see the PR description under "Why this is a behavior change worth taking." The creator-only canEditPadSettings server gate is unchanged, so this widens UI defaults but does not widen access. Operators who want the legacy single-section modal can still set enablePadWideSettings: false; the comment in both shipped settings files documents that path.

qodo-free-for-open-source-projects · 2026-05-05T17:00:53Z

      <div id="settings" class="popup" role="dialog" aria-modal="true" aria-labelledby="settings-title"><div class="popup-content">
-          <% if (settings.enablePadWideSettings) { %>
          <h1 id="settings-title" data-l10n-id="pad.settings.title">Settings</h1>
-          <% } else { %>
-          <h1 id="settings-title" data-l10n-id="pad.settings.padSettings">Pad Settings</h1>
-          <% } %>
          <div class="settings-sections">


2. No test for modal h1 📘 Rule violation ☼ Reliability

The PR fixes the settings modal heading logic by removing the conditional title, but it does not add a regression test that would fail if the old misleading heading behavior returned. This makes the UI bug fix unverifiable and prone to regression.

Agent Prompt

## Issue description The settings modal heading bug fix (always using `pad.settings.title` / `Settings`) has no automated regression coverage. ## Issue Context This PR changes the modal `<h1 id="settings-title">` rendering logic in `src/templates/pad.html`, but does not add a test that asserts the heading text/label under the relevant configuration states. ## Fix Focus Areas - src/templates/pad.html[129-138] - src/tests/frontend-new/specs/pad_settings.spec.ts[1-40]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Addressed in 912da32. Added tests/backend/specs/settingsModalHeading.ts which asserts data-l10n-id="pad.settings.title" is rendered for the modal H1 in both enablePadWideSettings states. If the old conditional (pad.settings.padSettings when the flag is off) is reintroduced, the disabled-flag test fails.

Asserts the rendered `/p/<id>` HTML always uses `data-l10n-id="pad.settings.title"` for the modal heading, regardless of `enablePadWideSettings`. Catches a re-introduction of the old conditional that printed "Pad-wide Settings" for every user when the feature was off. Action of Qodo review feedback on PR #7679.

qodo-free-for-open-source-projects Bot reviewed May 5, 2026

View reviewed changes

qodo-code-review Bot deleted a comment from qodo-free-for-open-source-projects Bot May 5, 2026

JohnMcLear requested a review from SamTV12345 May 5, 2026 19:25

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(settings): enable Pad-wide Settings by default; fix misleading modal title#7679

feat(settings): enable Pad-wide Settings by default; fix misleading modal title#7679
JohnMcLear wants to merge 2 commits intodevelopfrom
fix/pad-creator-settings

JohnMcLear commented May 5, 2026

Uh oh!

qodo-code-review Bot commented May 5, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented May 5, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented May 5, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot May 5, 2026

Uh oh!

JohnMcLear May 5, 2026

Uh oh!

qodo-free-for-open-source-projects Bot May 5, 2026

Uh oh!

JohnMcLear May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

JohnMcLear commented May 5, 2026

Summary

Why this is a behavior change worth taking

Server-side gate is unchanged

Test plan

Reviewer notes

Uh oh!

qodo-code-review Bot commented May 5, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented May 5, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-free-for-open-source-projects Bot commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot May 5, 2026

Choose a reason for hiding this comment

Uh oh!

JohnMcLear May 5, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-free-for-open-source-projects Bot May 5, 2026

Choose a reason for hiding this comment

Uh oh!

JohnMcLear May 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

qodo-free-for-open-source-projects Bot commented May 5, 2026 •

edited

Loading