Found while implementing #7231 (PR objectstack-ai/objectui#4071). Filed rather than fixed there — #7231's scope is the approvals entry only.
The finding
#7231 fixed one producer that hardcoded the setup app in a navigation target. Four siblings with the same shape were left in place, all reached by the same non-admin users:
packages/app-shell/src/console/home/HomePage.tsx:464 — onOpenNotification={(n) = > navigate(n.actionUrl || '/apps/setup/sys_inbox_message?view=mine')} (the fallback branch, taken whenever a notification carries no action_url)packages/app-shell/src/console/home/HomePage.tsx:472 — HomeActivity onViewAll → /apps/setup/sys_activitypackages/app-shell/src/layout/InboxPopover.tsx:129 — goToAllNotifications → /apps/setup/sys_inbox_message?view=minepackages/app-shell/src/layout/InboxPopover.tsx:137 — goToAllActivity → /apps/setup/sys_activity
The last two are the notable pair: the same component's goToApprovals (line 119) and handleNotificationClick (line 142) already resolve currentAppName ?? params.appName and prefix with it. The two "see all" drills sitting between them do not — they were written as deliberate exceptions, and the comment above goToAllNotifications says why: "Route through the setup app's sys_inbox_message list view — the canonical full-page inbox (ADR-0030 L5), outside per-app sidebars."
Why it is still worth a look
That comment argues the OBJECT is app-independent, which is true, and then picks setup as the app to render it in, which does not follow — sys_inbox_message and sys_activity are framework-owned objects reachable at /apps/{any app}/{object} exactly like system/approvals was. A business user with no access to the setup app therefore has a dead "see all" on both the bell popover and Home, while the approvals row directly above it now works.
I did not verify the failure end-to-end in a browser against a non-admin session, so the user-visible symptom (shell "App not available" guard vs. something softer) is inferred from the routing, not measured.
Deliberately excluded from this report
/apps/setup/system/marketplace (HomePage.tsx:395, HomeAppsStrip onBrowseMarketplace) and /apps/setup/system/apps are admin-scoped surfaces where setup is a defensible target rather than an oversight. They are listed here only so a fix does not sweep them in without a decision.
Suggested shape
If it is taken up: the same resolution #7231 introduced in HomePage (last-open app re-checked against the live active-app list, then first active app, setup last) applied to all four, or — better, if the four are agreed to be one surface — a single shared helper the popover and Home both call, which the #7231 PR deliberately did not create because it was out of scope there.
Found while implementing #7231 (PR objectstack-ai/objectui#4071). Filed rather than fixed there — #7231's scope is the approvals entry only.
The finding
#7231 fixed one producer that hardcoded the
setupapp in a navigation target. Four siblings with the same shape were left in place, all reached by the same non-admin users:packages/app-shell/src/console/home/HomePage.tsx:464—onOpenNotification={(n) => navigate(n.actionUrl || '/apps/setup/sys_inbox_message?view=mine')}(the fallback branch, taken whenever a notification carries noaction_url)packages/app-shell/src/console/home/HomePage.tsx:472—HomeActivity onViewAll→/apps/setup/sys_activitypackages/app-shell/src/layout/InboxPopover.tsx:129—goToAllNotifications→/apps/setup/sys_inbox_message?view=minepackages/app-shell/src/layout/InboxPopover.tsx:137—goToAllActivity→/apps/setup/sys_activityThe last two are the notable pair: the same component's
goToApprovals(line 119) andhandleNotificationClick(line 142) already resolvecurrentAppName ?? params.appNameand prefix with it. The two "see all" drills sitting between them do not — they were written as deliberate exceptions, and the comment abovegoToAllNotificationssays why: "Route through the setup app'ssys_inbox_messagelist view — the canonical full-page inbox (ADR-0030 L5), outside per-app sidebars."Why it is still worth a look
That comment argues the OBJECT is app-independent, which is true, and then picks
setupas the app to render it in, which does not follow —sys_inbox_messageandsys_activityare framework-owned objects reachable at/apps/{any app}/{object}exactly likesystem/approvalswas. A business user with no access to the setup app therefore has a dead "see all" on both the bell popover and Home, while the approvals row directly above it now works.I did not verify the failure end-to-end in a browser against a non-admin session, so the user-visible symptom (shell "App not available" guard vs. something softer) is inferred from the routing, not measured.
Deliberately excluded from this report
/apps/setup/system/marketplace(HomePage.tsx:395,HomeAppsStrip onBrowseMarketplace) and/apps/setup/system/appsare admin-scoped surfaces wheresetupis a defensible target rather than an oversight. They are listed here only so a fix does not sweep them in without a decision.Suggested shape
If it is taken up: the same resolution #7231 introduced in
HomePage(last-open app re-checked against the live active-app list, then first active app,setuplast) applied to all four, or — better, if the four are agreed to be one surface — a single shared helper the popover and Home both call, which the #7231 PR deliberately did not create because it was out of scope there.