fix: persist welcome-dialog dismissal when Desktop Mode is disabled#303
Merged
Conversation
The first-run "Welcome to Desktop Mode" dialog renders in the classic admin only while Desktop Mode is *disabled* (it is a "switch to Desktop Mode" promo). Its dismissal POSTs the `activation-welcome` slug to /desktop-mode/v1/intros/seen, but that route's permission callback is desktop_mode_rest_require_enabled(), which returns 403 whenever Desktop Mode is not enabled. Because that is the only state the dialog ever appears in, the dismissal could never persist, so the dialog re-rendered on every classic-admin page load. Scope a single-slug exception in desktop_mode_rest_seen_intros_permission(): the `activation-welcome` slug is accepted from any logged-in, read-capable account (the exact audience the dialog is shown to), while every other (in-shell) intro slug keeps the strict enabled gate. The DELETE /intros "Reset what's-new dialogs" route carries no slug and is unaffected. Adds regression tests covering both the welcome-slug bypass and the unchanged strict gate for other slugs, and documents the dismissal behavior in the welcome-dialog hook reference.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The first-run Welcome to Desktop Mode dialog re-appears on every classic-admin page load and can never be dismissed for good, even after clicking Got it / × / Escape.
It is, by design, an invite shown in the classic admin only while Desktop Mode is disabled for the user. Dismissing it POSTs the
activation-welcomeslug toPOST /desktop-mode/v1/intros/seento remember the dismissal. But that route's permission callback isdesktop_mode_rest_require_enabled(), which returns 403 whenever Desktop Mode is not enabled, which is the only state the dialog ever appears in. So the dismissal could never persist → the dialog showed forever.This is a Catch-22 introduced when the seen-intros route was hardened to require Desktop Mode enabled (previously
read), while the welcome dialog, added later, reused that same endpoint.Fix
Scope a single-slug exception in
desktop_mode_rest_seen_intros_permission():activation-welcomeslug is accepted from any logged-in,read-capable account (the exact audience the dialog is shown to). Writing one's own dismissal flag carries no privileged surface.DELETE /intros("Reset what's-new dialogs") route carries no slug and is unaffected.Net behavior: the welcome invite now shows once after activation, stays dismissed, and never shows once Desktop Mode is enabled.
Tests
activation-welcomedismissal (200, recorded).posts) is still rejected (403).build,lint,typecheck,test:js(1568),test:phpfor the affected classes (20 tests).Docs
Updated the
desktop_mode_show_welcome_dialogentry indocs/hooks-reference.mdto document the not-enabled gate and the scoped dismissal-persistence exception.