feat: unattended active rundown view

[justandras]

About the Contributor

This pull request is posted on behalf of the BBC.

Type of Contribution

This is a:

Feature

Current Behavior

The Active Rundown view (/activeRundown/:studioId) follows the studio’s active playlist, but operators can leave via the header close button, the context menu “Close Rundown” action. After leaving to the lobby, they are not automatically returned when another rundown is activated.

When no rundown is active, the view shows a static message with a “Return to list” link.

New Behavior

• Active Rundown — The Active Rundown routes are always locked for unattended/kiosk use. There is no URL parameter to enable or disable this.
• Exit controls hidden — header close (X), context menu “Close Rundown”, and the React Router navigation Prompt are disabled.
• Idle state — when no rundown is active and lockView=1, shows StudioScreenSaver (same as prompter/director) instead of the “no active rundown” message and return link.

Example URLs:

/activeRundown/{studioId}
/activeRundown/{studioId}/shelf?layout=...

Note: lockView does not block browser back, manual URL changes, or tab close.

Testing

• I have added one or more unit tests for this PR
• I have updated the relevant unit tests
• No unit test changes are needed for this PR

Manual testing:

1. /activeRundown/{studioId} with an active playlist — no X, no “Close Rundown”, no in-app navigation prompt; header layout unchanged.
2. Same URL with no active playlist — StudioScreenSaver shown (not the old message + return link).
3. /rundown/{playlistId} — exit controls and idle behavior unchanged (locking does not apply).
4. /activeRundown/{studioId}/shelf — same locked behavior when applicable.

Affected areas

• Active Rundown view (ActiveRundownView)
• Rundown view header and context menu (RundownHeader, RundownContextMenu)

Time Frame

Not urgent, but we would like to get this merged into the in-development release.

Other Information

First step toward unattended Active Rundown displays; auto-return from lobby when a rundown activates is out of scope for this PR.

Per review feedback, locking is the default (and only) behavior on Active Rundown routes rather than an opt-in query parameter.

Status

• PR is ready to be reviewed.
• The functionality has been tested by the author.
• Relevant unit tests has been added / updated.
• Relevant documentation (code comments, system documentation) has been added / updated.

[coderabbitai]

Walkthrough

This PR adds a lockView query parameter to lock the Active Rundown screen for kiosk/unattended use. When enabled, it shows a screensaver in ActiveRundownView, disables exit controls in RundownHeader, hides the close action in RundownContextMenu, and suppresses navigation confirmation prompts.

Changes

Lock View Feature Implementation

Layer / File(s)	Summary
Feature Documentation packages/documentation/docs/for-developers/url-query-parameters.md, packages/documentation/docs/user-guide/features/sofie-views-and-screens.mdx	Documented lockView=1 parameter behavior, route applicability, example URLs, and updated Screensaver description to reference Active Rundown with kiosk mode.
ActiveRundownView Screensaver Display packages/webui/src/client/ui/ActiveRundownView.tsx	Imports StudioScreenSaver and useLocation, parses lockView from the URL query string, and returns the screensaver component when lockView=1 instead of rendering the normal active rundown.
RundownView Prop Calculation and Propagation packages/webui/src/client/ui/RundownView.tsx	Calculates lockView boolean from the URL query parameter and inActiveRundownView prop, extends component interfaces to include the prop, and wires it through RundownViewContent and RundownHeader. Updates the navigation Prompt to suppress confirmation when lockView is true.
RundownHeader Exit Control Conditional Rendering packages/webui/src/client/ui/RundownView/RundownHeader/RundownHeader.tsx, packages/webui/src/client/ui/RundownView/RundownHeader/RundownHeader.scss, packages/webui/src/client/ui/RundownView/RundownHeader/RundownContextMenu.tsx	RundownHeader receives lockView prop and conditionally renders the close button as a non-interactive placeholder span (with visibility: hidden and pointer-events: none) when locked, or as a normal NavLink otherwise. RundownContextMenu receives lockView and hides the "Close Rundown" menu action when locked.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat: unattended active rundown view' directly and concisely describes the main feature being added—a kiosk/unattended mode for the Active Rundown view, which aligns with the primary changes across documentation and components.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description check	✅ Passed	The pull request description clearly and comprehensively describes the new lockView feature for the Active Rundown view, including current behavior, new behavior, testing steps, and affected areas.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/webui/src/client/ui/RundownView.tsx`:
- Around line 1522-1524: The beforeunload listener registered by
handleBeforeUnloadEventAttach is still added even when lockView is true, so
browser/tab close still shows a leave confirmation; update
handleBeforeUnloadEventAttach to only add the window.beforeunload listener when
!this.props.lockView (and ensure handleBeforeUnloadEventDetach removes it when
appropriate), and update places that call these helpers (e.g.,
componentDidMount/componentDidUpdate or wherever handleBeforeUnloadEventAttach
is invoked in RundownView.tsx) to respect this.props.lockView so the listener is
never attached for locked screens and is removed when lockView becomes
true->false.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d8163ec0-eb42-4ade-8014-f0905ac64a57

📥 Commits

Reviewing files that changed from the base of the PR and between 63f4ff9 and 44b581f.

📒 Files selected for processing (7)

• packages/documentation/docs/for-developers/url-query-parameters.md
• packages/documentation/docs/user-guide/features/sofie-views-and-screens.mdx
• packages/webui/src/client/ui/ActiveRundownView.tsx
• packages/webui/src/client/ui/RundownView.tsx
• packages/webui/src/client/ui/RundownView/RundownHeader/RundownContextMenu.tsx
• packages/webui/src/client/ui/RundownView/RundownHeader/RundownHeader.scss
• packages/webui/src/client/ui/RundownView/RundownHeader/RundownHeader.tsx

[Julusian]

do we need a url parameter, or could this be the only behaviour on this screen?
I cant think of when someone would use this and want to be able to navigate away as sofie doesnt give them a way to return to this

I'm worried about this being another 'secret' option/parameter when in my mind the default usage of this is for renderering on an unattended screen