Fix: Incorrect Error Message and UI issues for Non-Super Users on Request Actions

[mridxl]

Date: 14 Mar 2025

Developer Name: @mridxl

---

Issue Ticket Number

• Closes Bug: Incorrect Error Message & UI Issue on "Accept"/"Reject" for Non-Super Users #959

Description

This PR fixes the incorrect error message shown when a non-super user clicks the "Accept" or "Reject" button on requests. Additionally, it ensures that request cards remain visible on the page instead of disappearing when an error occurs. The error message will now be displayed only via a toast notification without altering the state of the request list.

Documentation Updated?

• Yes
• No

Under Feature Flag

• Yes
• No

Database Changes

• Yes
• No

Breaking Changes

• Yes
• No

Development Tested?

• Yes
• No

Screenshots

Screenshot 1

Screen Recording

Recording.2025-03-14.170913.mp4

Test Coverage

Screenshot 1

[coderabbitai]

Summary by CodeRabbit

• New Features
  • Introduced a refined error message for unauthorized actions.
  • Enhanced request processing by ensuring the interface refreshes automatically after actions are performed.

Walkthrough

The pull request adds a new error message constant for unauthorized actions in the application's error handling. The ErrorMessages object in requests/constants.js now includes the UNAUTHORIZED_ACTION key with an appropriate message. In requests/script.js, the error handling logic within the acceptRejectRequest function is updated to use this new constant for HTTP 401 responses, while HTTP 403 handling remains unchanged. Additionally, the performAcceptRejectAction function now resets the nextLink variable and triggers a re-rendering of request cards with current state and sort parameters.

Changes

File(s)	Change Summary
requests/constants.js	Added a new constant UNAUTHORIZED_ACTION with value "You are unauthorized to perform this action" to the ErrorMessages object.
requests/script.js	Updated acceptRejectRequest to use ErrorMessages.UNAUTHORIZED_ACTION for status 401; added a reset of nextLink and a call to renderRequestCards in performAcceptRejectAction.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant ReqHandler as acceptRejectRequest
    participant ActionHandler as performAcceptRejectAction
    participant UI as renderRequestCards
    participant ErrMsg as ErrorMessages

    User->>ReqHandler: Trigger acceptRejectRequest
    alt HTTP 401 Response
        ReqHandler->>ErrMsg: Retrieve UNAUTHORIZED_ACTION message
        ErrMsg--)ReqHandler: Return error message
    else HTTP 403 Response
        ReqHandler->>ErrMsg: Retrieve UNAUTHENTICATED message
        ErrMsg--)ReqHandler: Return error message
    end
    ActionHandler->>ActionHandler: Reset nextLink to empty
    ActionHandler->>UI: Re-render request cards (current state & sort)

Loading

Poem

Oh, I hop with joyful glee,
New messages set my code free!
Unauthorized now gets its note,
In error handling, I proudly tote.
Request cards dance in a re-rendering spree,
A bunny's code delight, as happy as can be!
🐇💻✨

Tip

⚡🧪 Multi-step agentic review comment chat (experimental)

• We're introducing multi-step agentic chat in review comments. This experimental feature enhances review discussions with the CodeRabbit agentic chat by enabling advanced interactions, including the ability to create pull requests directly from comments.
  - To enable this feature, set early_access to true under in the settings.

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 26cdeeb and e06f6ec.

📒 Files selected for processing (2)

• requests/constants.js (1 hunks)
• requests/script.js (2 hunks)

🔇 Additional comments (3)

requests/constants.js (1)

30-30: Good addition of a specific error message for unauthorized actions.

Adding this new error message constant provides a more accurate description for situations where users attempt actions they don't have permission for, which aligns well with the PR objective of improving error messaging for non-super users.

requests/script.js (2)

513-516: Appropriate update to error messaging for unauthorized actions.

The error handling for HTTP 401 responses now correctly uses the new UNAUTHORIZED_ACTION constant instead of UNAUTHENTICATED, which better reflects that the user is logged in but lacks permissions to perform the action. This is a key fix addressing the problem described in the PR.

---

589-591: Good fix to ensure UI consistency after failed actions.

These added lines resolve the core issue by resetting the pagination link and re-rendering the request cards with the current state after an action is performed (successful or not). This ensures the request cards remain visible on the page even when an error occurs, preventing the UI from being in an inconsistent state.

✨ Finishing Touches

• 📝 Generate Docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[AnujChhikara]

Could you please add a video in the description for better clarity? Also, is it appropriate to display the error message in both the toast and the body?

[mridxl]

Could you please add a video in the description for better clarity?

Yes, I've added the video in the description.

Also, is it appropriate to display the error message in both the toast and the body?

The error message was being displayed in the body earlier, so I assumed that was how we wanted it to be.
IMO, we should only display a toast to notify the user and not display the error in the body.

[AnujChhikara]

Could you please add a video in the description for better clarity?

Yes, I've added the video in the description.

Also, is it appropriate to display the error message in both the toast and the body?

The error message was being displayed in the body earlier, so I assumed that was how we wanted it to be. IMO, we should only display a toast to notify the user and not display the error in the body.

A toast seems sufficient for notifying the user—maybe we can check with others for their input. Also, since we're re-rendering the cards, is there a way to prevent that when an error occurs to avoid an extra DB call?

[MayankBansal12]

@mridxl remove Additional Notes...not needed here!

[mridxl]

Also, since we're re-rendering the cards, is there a way to prevent that when an error occurs to avoid an extra DB call?

Yes, we can consider one of two approaches:

• Store the fetched requests in a variable before making the API call.
  If an error occurs, we can re-render the cards using the saved state instead of making another DB call.

• Avoid modifying the UI when an error occurs.
  Instead of removing or re-rendering the cards when the user clicks the accept/reject button (and showing the loading spinner), we can display an error toast directly.

I prefer the second approach. Since the state of the requests doesn’t change when an error occurs, there’s no need to modify the UI. We can just show the user an error toast to notify them of the issue. If the API call is successful, we can then refetch the requests and re-render the cards (along with a loading spinner to indicate the update).