sadpandajoe opened a new pull request, #41402:
URL: https://github.com/apache/superset/pull/41402

   ### SUMMARY
   
   When a non-owner user opens a draft dashboard by direct URL, the `GET 
/api/v1/dashboard/favorite_status/` endpoint correctly returns 404 (draft 
dashboard visibility is owner/admin-only at the API layer). However, 
`fetchFaveStar`'s `.catch` handler treated every error uniformly and surfaced a 
danger toast: *"There was an issue fetching the favorite status of this 
dashboard."*
   
   A 404 here means "favorite status isn't available to this user" — it is not 
an error worth alarming the user about. This also covers the case where a 
dashboard is deleted after navigation began.
   
   **Fix:** In `fetchFaveStar`'s `.catch`, use the already-imported 
`getClientErrorObject` helper to extract the response status. If `status === 
404`, return silently instead of dispatching the danger toast. Non-404 errors 
(network failures, 500s) continue to toast when the dashboard ID still matches, 
preserving the existing `currentId === id` race-condition guard.
   
   Related: #33007 (closed unmerged) addressed the same symptom for the 
deleted-dashboard case. This PR covers both the draft-non-owner case and the 
deleted case with the same 404 check.
   
   ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
   
   **Before:** Non-owner loads a draft dashboard → red danger toast appears on 
load.
   **After:** No toast. The 404 from `favorite_status` is silently swallowed.
   
   ### TESTING INSTRUCTIONS
   
   1. As an admin, create a dashboard and leave it in draft (unpublished) state.
   2. As a non-admin user who is NOT the dashboard owner, navigate directly to 
the dashboard URL.
   3. **Before this fix:** a red danger toast "There was an issue fetching the 
favorite status of this dashboard." appears.
   4. **After this fix:** no toast appears.
   5. Verify that genuine network errors (e.g. disconnect) still produce the 
toast on a published dashboard.
   
   Automated: `npm run test -- src/dashboard/actions/dashboardState.test.ts` — 
the new test `'does NOT dispatch a danger toast on 404 error when the dashboard 
ID still matches'` covers the fix, and the existing `'dispatches a danger toast 
on error when the dashboard ID still matches'` (non-404) confirms non-404 
errors still toast.
   
   ### ADDITIONAL INFORMATION
   - [ ] Has associated issue:
   - [ ] Required feature flags:
   - [x] Changes UI
   - [ ] Includes DB Migration (follow approval process in 
[SIP-59](https://github.com/apache/superset/issues/13351))
     - [ ] Migration is atomic, supports rollback & is backwards-compatible
     - [ ] Confirm DB migration upgrade and downgrade tested
     - [ ] Runtime estimates and downtime expectations provided
   - [ ] Introduces new feature or API
   - [ ] Removes existing feature or API


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to