[DO NOT MERGE]: unstable to hotfixes, Q1 major release

[marcellamaki]

Summary

…

Vuetify → KDS Migration

View QA guidance

Tracking issue: #5060

This overview sets the scope of regression testing needed before release. The refactoring work replaces Vuetify components with Kolibri Design System (KDS) components across Studio. For each workflow, we're primarily focused on interactions and functionality — making sure nothing broke in the migration. Some minor visual differences are expected and noted below.

For detailed context on any specific change, issue links are included per section. When in doubt about whether something is a regression or an intentional change, check the linked issues.

General notes:

• Compare production vs. unstable
• All modals will have some visual differences due to switching to KDS — this is expected and not a concern (see the Settings section for a visual example). Focus on whether the modal opens, functions correctly, and closes correctly.
• Radina: a11y testing across all workflows is very welcome as time allows.

---

1. Settings (`/settings`)

We're regression testing all 3 tabs. The priority is interactions and functionality.

What changed: Page layout, offline alert bar, and several components across the Account and Storage tabs were migrated from Vuetify to KDS.

Account tab:

• Change password form — test that the form opens, validation works, and a password can be changed successfully
• Copy token input — test copy interaction
• "Failed to delete account" alert — trigger and confirm it displays correctly
• "Data export started" alert — trigger and confirm it displays

Storage tab:

• Storage overview loader — confirm it shows correctly while loading
• "Request more space" form — test the slide transition opening, form validation (error banner), and successful submission
• "About licenses" modal — open it and confirm all links inside are functional

General:

• Offline alert bar — confirm it appears correctly when offline
• All buttons, links, and interactive elements across the page

Visual differences: Modals (e.g., "About licenses", "Request more space") will look slightly different from production due to KDS styling. Functionality is the priority.

Related issues: #5061, #5062, #5063, #5064, #5080, #5081, #5082, #5092, #5095, #5123, #5127, #5132

2. Channels (`/channels`)

Several distinct sub-areas were touched here. Test each sub-area as a workflow.

What changed: Channel cards across all channel listing views, channel detail pages, channel collections, the Content Library, error pages, and several modals were all migrated.

2a. Channel listing views (My Channels, Starred, View-only)

• Channel cards render correctly in all three views (My Channels, Starred, View-only)
• Top-level buttons (e.g., create channel, search) work as expected
• Offline alert bar appears when offline
• Channel card interactions: open a channel, star/unstar, and any context menu or overflow actions

Related issues: #5218, #5219, #5227, #5524, #5525

2b. Channel detail page

• Channel detail page layout and content load correctly
• Edit channel details — confirm buttons work and changes save
• Channel collection options (dropdown or context menu actions on a collection)
• Invitations — send an invite, confirm UI for pending/accepted states
• Channel collections table — confirm it renders and is interactive

Visual differences: Modals on the channel detail page (e.g., unsaved changes) will look slightly different.

Related issues: #5217, #5474, #5484, #5485, #5529, #5530

2c. New collection / Unsaved changes

• Create a new collection — confirm buttons work, collection name input and validation behaves correctly (test empty submission and character limits)
• Collection channels loader — confirm loading state displays
• "Unsaved changes" modal — navigate away with unsaved changes and confirm modal appears and both actions (discard / keep editing) work

Visual differences: "Unsaved changes" modal will look slightly different from production.

Related issues: #5243, #5244, #5298, #5299

2d. Content Library

• Content Library catalog page loads correctly
• Cards render correctly
• Buttons, links, and dropdown interactions work
• Side panel opens and closes correctly
• FAQ page ("Frequently asked questions") renders and links work
• "About collections" modal — open and confirm links are functional

Visual differences: "About collections" modal will look slightly different.

Related issues: #5234, #5471, #5502, #5526, #5528

2e. Error pages

• "Channel not found" — trigger by navigating to an invalid channel URL
• "Page not found" — trigger with a bad route
• "Something went wrong" — if triggerable, confirm rendering
• "Did you forget to sign in?" — confirm this renders when accessing a protected channel while logged out

Related issues: #5235, #5295, #5296, #5297

3. Channel Editor

The channel editor had the most changes across this migration — many dialogs and action buttons throughout the editing workflow were updated. Test these as you would a normal editing session, but make a point to trigger each dialog.

What changed: Buttons and dialogs throughout the editing workflow — move, upload, questions, import, and several confirmation dialogs.

Organize / Move:

• Move modal — open it, confirm buttons work, and create a new folder from within the modal (the "create new folder" dialog inside Move)

Upload:

• Upload files — confirm upload buttons work and the upload flow completes
• Upload in progress dialog — confirm it displays during upload
• Save failed dialog — confirm it displays on a save failure (may need to simulate)

Questions:

• Questions tab — confirm buttons work
• Change question type — confirm the confirmation dialog appears and both actions (confirm / cancel) work

Content actions:

• Finish button — confirm it works and the "Incomplete resource" modal appears when applicable
• Permanently delete resource — confirm the confirmation dialog appears and deletion works
• Alert dialog — confirm it appears and responds correctly

Related tab:

• Confirm buttons and links in the Related tab are functional
• Add previous / next step buttons work

File preview:

• View fullscreen and exit fullscreen buttons work

Import from channels:

• Buttons and links in Import from Channels work
• Saved searches — save a search, confirm the saved search dialogs work (save, view, delete)

Navigation / errors:

• "Channel not found" error page renders correctly in the editor context

Visual differences: All dialogs/modals in the channel editor (move, upload, confirm delete, change question type, etc.) will look slightly different from production.

Related issues: #5355, #5375, #5376, #5377, #5378, #5379, #5420, #5421, #5422, #5423, #5442, #5443, #5444, #5470, #5472, #5473

4. Accounts

These are the pre-login and account lifecycle pages. Testing is straightforward — confirm all interactive elements function correctly.

What changed: Buttons and links on the sign-in, account created, and account deleted pages; various informative pages.

• Sign-in page — confirm all buttons and links work (sign in, forgot password link, create account link)
• Account created page — confirm the page renders and any buttons/links function
• Account deleted page — confirm the page renders and any buttons/links function
• Informative pages (e.g., activation failed, reset password) — confirm these render correctly and interactive elements work

Related issues: #5352, #5353, #5534, #5631, #5632, #5633, #5636, #5637

5. Administration (`/administration`)

Admin-only pages. Confirm all management actions and their confirmation dialogs work end-to-end.

What changed: Buttons and confirmation dialogs for user and channel management actions; the send email dialog.

Users:

• Disk space popup — trigger from the Users table (storage icon or similar) and confirm it opens/displays correctly
• Deactivate user — trigger confirmation dialog, confirm both actions work
• Delete user — trigger confirmation dialog, confirm both actions work
• Add / remove admin privileges — trigger dialogs and confirm both actions work

Channels:

• Delete channel — trigger confirmation dialog and confirm
• Restore channel — trigger confirmation dialog and confirm
• Toggle visibility — trigger confirmation dialog and confirm

Email:

• Send email dialog — trigger, confirm it opens, and test sending

Visual differences: All confirmation dialogs and the send email dialog will look slightly different from production.

Related issues: #5354, #5410, #5411, #5425, #5441

6. Policy modals

Policy modals

• Trigger policy modals wherever they appear (e.g., Terms of Service, Privacy Policy links in footer or sign-in)
• Confirm they open, render content, and close correctly
• Confirm any links within the modals are functional* (note, pending is the DCMA form fix-- which as of 9 March is only in hotfixes)

Visual differences: Policy modals will look slightly different from production.

Related issues: #5651

Reviewer guidance

AI usage

Significant Claude help in drafting QA team guidance

To fix this, explicitly declare permissions for the job (or globally) so the GITHUB_TOKEN is limited to the least privileges needed. Since this workflow only delegates to a reusable workflow and does not itself perform any repository writes, a safe, minimal default is read-only access to repository contents. That both satisfies CodeQL and avoids unintentionally granting write access via inherited defaults.

The best fix, without changing existing functionality, is to add a permissions block under the call-workflow job, e.g.:

jobs:
  call-workflow:
    permissions:
      contents: read
    name: Call shared workflow
    uses: ...

Placing it at the job level ensures the restriction applies specifically to this job, and avoids assumptions about other jobs (there are none currently, but this keeps the change tightly scoped). No imports or additional definitions are needed; this is a pure YAML configuration change within .github/workflows/call-contributor-pr-reply.yml. Insert the new permissions block between call-workflow: and name: with correct indentation.

In general, the fix is to explicitly declare a permissions block that limits the GITHUB_TOKEN to the least privileges needed. This can be done at the workflow root (applies to all jobs) or at the job level. Because this workflow only has a single job and we want to minimize changes, we can add a root-level permissions block just under the name: line. For a pull_request_target workflow that primarily reads repository contents and PR metadata while deferring actual actions to a reusable workflow using app credentials, a safe minimal baseline is contents: read. If the reusable workflow requires additional scopes, it will typically define them itself; in this caller it is reasonable to keep the token read-only.

Concretely, in .github/workflows/call-pull-request-target.yml, add:

permissions:
  contents: read

between line 1 (name: Handle pull request events) and line 2 (on:). No imports or additional methods are required since this is a YAML configuration change only and does not affect existing behavior, other than constraining the automatically provided GITHUB_TOKEN to read access to contents.