self serve if the site is not registered for Publish request#43
Open
ravuthu wants to merge 22 commits into
Open
self serve if the site is not registered for Publish request#43ravuthu wants to merge 22 commits into
ravuthu wants to merge 22 commits into
Conversation
…s Inbox DA-native visual alignment for both the request-for-publish plugin and the publish-requests-inbox app. Plugin and app: - Adopt nexter design tokens, buttons.css, SL styles; flatten UI chrome - Per-customer accent color override via workflow-settings (theme.*) - Load nexter.css in plugin and app HTML for token inheritance - Consistent typography, spacing, form, and link treatments - Subtle red .message.error banner with DA-native styling; other message variants aligned (success, info, warning) Plugin (request-for-publish): - Polish My Requests (requester) view for visual consistency - Dedicated withdrawn screen instead of falling back to form - Consolidate validation and backend errors on _message via renderMessage() so backend errors surface in the form - <code>-wrapped emails and paths for scannability - Consistent 700 font-weight on links; aligned dd/code padding App (publish-requests-inbox): - Tighten inbox rows, remove empty icon spans - Approvers section uses accent-derived color-mix highlight - Negative (red) button for Reject Request - Muted gray reject toggle; primary class for reject button - Override nexter.css body grid layout in app iframe - Neutral gray loading spinner to avoid accent color flash Misc: - Add loadButtons helper for nexter button styles - Match nexter specificity for disabled accent buttons; preserve white text on disabled accent buttons - Replace hardcoded blue with accent-derived colors throughout Made-with: Cursor
|
Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
|
sagarsane
reviewed
Apr 20, 2026
Collaborator
|
I don't think this is working .. I went to https://da.live/app/aemsites/da-blog-tools/tools/apps/publish-requests-inbox/publish-requests-inbox?org=sagarsane&site=sagarsane-store&ref=self-serve, I confirmed 
|
sagarsane
reviewed
Apr 20, 2026
sagarsane
reviewed
Apr 20, 2026
…ields for custom-api
Collaborator
Author
This is due to worker changes not being deployed. It should work fine after deploying the self-serve branch. I deployed and tested in the CI environment, which is working fine. |
- Hide the "Publish Request Inbox" header and org/site input on the unregistered-site screen; the registration form is the only useful action there, so keeping the toolbar around just adds noise. - Rename the "MailChannels (default)" provider option to "Default" — the underlying transport is an implementation detail (and is now AWS SES anyway), not something authors need to see. - Drop the now-stale "Gmail" provider label; the worker no longer advertises gmail, so authors will never see it in the dropdown. Made-with: Cursor
Two small inbox UX fixes following the self-serve registration flow:
1. The toolbar's primary button stayed at "Loading..." after a
successful registration. Cause: _siteSelectLoading was being
mutated in handleRegister (true → finally → false) but it was
never declared as a Lit reactive state property and never
initialised in the constructor. handleRegister's final
_siteSelectLoading = false therefore did not trigger a re-render,
so the toolbar was last drawn while it was still true. Add it to
the static properties block and initialise it to false.
2. After registering a site the success banner ("Site .../...
registered successfully!") appeared between the "Publish Request
Inbox" title and the inbox content, which buries the most
important confirmation. Render the message above the toolbar so it
sits at the very top of the view.
Made-with: Cursor
Previously the unregistered-site view rendered a "Site Not Registered" banner with a "Register Site" button, and clicking it expanded the registration form below. The intermediate click was busywork — a user who has navigated to the inbox for an unregistered site is, by definition, here to register it. Drop the toggle entirely: - Render the registration form unconditionally inside renderUnregistered. - Remove the "Register Site" expand button and the form's "Cancel" button (there is no intermediate state left to fall back to; users can change the org/site input or navigate away). - Remove the _showRegisterForm reactive prop, its constructor init, the toggleRegisterForm() method, and all its assignment sites. - Re-key the global-message suppression on _state === 'unregistered' instead of _showRegisterForm — the registration form still has its own inline renderMessage() so we don't want a duplicate at the top while the user is filling it out. Made-with: Cursor
After the registration check passes, verify the DA-side workflow setup (library tab, apps tab, publish-workflow-config tab) before loading the inbox. The publish-workflow-config tab is required and blocks with a new full-page "DA Configuration Required" view that lists each tab's status, links to the setup docs, and offers an inline re-check. Library/apps tab statuses are tracked and surfaced inside that view but do not block on their own — they affect the author plugin flow rather than the approver inbox. Made-with: Cursor
Inspect publish-workflow-settings and publish-workflow-groups-to-email alongside the existing required tabs, and surface the full picture through a small "Setup" pill in the toolbar that opens a lazy panel listing each tab's status with site/org provenance. Smart status states avoid false alarms: - workflow-settings: 'default' (tab absent → using documented defaults) vs 'empty' (tab present, zero rows → likely authoring mistake) - groups-to-email: 'not-needed' when no distribution list names appear in publish-workflow-config approvers/CC, otherwise 'ok' or 'missing' Refactor the DA-config fetch path to halve boot fetches for happy-path users: a single fetchSiteAndOrgConfig call powers both the setup check and accent-color extraction (previously fetched twice in parallel). Made-with: Cursor
- Hide site-select input + "View publish requests" button when setupHealth is 'attention', so users finish optional setup (library, apps, publish-workflow-settings, groups-to-email) before entering the inbox. - Auto-expand the Setup panel right after a successful registration if anything needs attention, so the orange dot isn't missed at the one moment we have the user's attention. - Reword the 'not-needed' status to "Not needed — approver rules use individual emails" so users understand why the publish-workflow-groups-to-email tab can be skipped. Made-with: Cursor
Removes the toolbar Setup pill + dropdown panel and consolidates onto the existing center-aligned setup screen. Approvers and requesters now land directly on the inbox when their site is properly configured; when it isn't, they see one consistent screen explaining what's missing. - Promote `library` and `apps` to required alongside `publish-workflow-config`. Without all three, no publish requests can ever reach the inbox, so blocking on them is more honest than rendering "No Pending Requests" indefinitely. - Drop the toolbar Setup pill, dropdown panel, `_setupPanelOpen` state, `setupHealth` getter, and post-registration auto-expand. - Show org/site as a small chip on the setup screen so admins know exactly which site they're configuring. - Update copy to explicitly call out all three required tabs and explain why they're required (no requests can reach the inbox). - Keep `publish-workflow-settings` and `publish-workflow-groups-to-email` as informational rows on the setup screen but they never gate the inbox. Made-with: Cursor
The previous `endsWith('/.../request-for-publish.html')` check failed for
real-world `path` values that include env refs (`?env=ci`), omit the
`.html` extension, or come from forked deployments. As a result,
properly-configured sites were being reported as "Not configured" and
incorrectly funnelled to the setup screen.
Switch both library and apps inspectors to a case-insensitive substring
check against a stable directory needle:
- library: path must contain `/tools/plugins/request-for-publish`
- apps: path must contain `/tools/apps/publish-requests-inbox`
This matches all known URL variations while still rejecting library/apps
sheets that don't reference the request-publish plugin at all.
Made-with: Cursor
Inline 'this site' and 'the org' links in the setup-screen footer point straight at the DA config editor for the relevant scope, removing the manual URL construction step for admins doing first-time setup. Both links are exposed because workflow config can legitimately live at either the site or org level (the inbox already does per-tab fallback); making the user pick is honest about that ambiguity rather than guessing. Open in a new tab so the inbox session is preserved for the post-fix re-check. Made-with: Cursor
Splits the run-on footer paragraph into a scannable two-bullet list that explains each scope's effect, and folds the precedence rule into the org-level bullet where it actually matters: - Site only -> applies only to <org>/<site> - Org -> applies to every site under <org>, unless overridden at site level (site-level wins when both define the same tab) The DA config editor links remain inline within each bullet so users can act on the choice they just read about. Required-tabs reminder and docs link stay as a separate trailing paragraph. Made-with: Cursor
When a site is registered but its publish-workflow-config tab is missing, render the same status-page pattern as the unregistered case (with copy adjusted to "Setup Incomplete") and link the user to the Publish Requests Inbox app to finish setup. Hides the form entirely so authors can't attempt to submit a request that would have no approvers. The "no matching rule for this path" error keeps its inline banner since that's a different problem (admin needs to add a path rule, not run initial setup). Made-with: Cursor
DA's per-site Library and Apps surfaces only read from the site-level config sheet — they are not inherited from org config. The setup checker was incorrectly falling back to orgConfig for these two tabs, which could mask a missing site-level config and would also misattribute provenance as "org-level" in the status row. - api.js: add inspectAtSiteOnly helper; use it for library + apps so org config is never consulted for them. Workflow tabs continue to use the documented site-first / org-fallback behavior. - publish-requests-inbox.js: rewrite the "where to add these tabs" bullets in the DA Configuration Required screen to make the per-tab scope rules explicit (library + apps must live in site config; only the publish-workflow-* tabs can be inherited from org). Made-with: Cursor
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
2 participants
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.
Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #
Test URLs: