Skip to content

fix: Correct Peer Review Workflow and UI

Edouard Legoupil requested to merge feature/multi-issue-fixes-and-features into main_dev

Created by: Edouard-Legoupil

This commit addresses several issues related to the peer review workflow, including a critical database error and UI/UX inconsistencies.

  1. Fix Peer Review Submission (submit_for_review):

    • Issue: A "duplicate key" database error occurred when assigning a review to the same user for the same proposal more than once. This caused a 500 server error and made the UI unresponsive.
    • Fix: The INSERT statement in the submit_for_review endpoint (backend/api/proposals.py) has been changed to an INSERT ... ON CONFLICT ... DO UPDATE statement. This makes the operation idempotent, preventing errors on resubmission and ensuring existing review requests can be updated (e.g., with a new deadline).

  2. Fix Peer Review Modal UI:

    • Issue: The "Close" and "Confirm" buttons in the peer review selection modal were rendered without any space between them.
    • Fix: CSS has been added to the MultiSelectModal component to add a gap between the action buttons, improving the visual layout.

  3. Address Status Inconsistency:

    • Issue: After submitting a proposal for review, the status badge on the author's screen did not immediately update from "Drafting" to "Peer Review".
    • Fix: The frontend logic in Chat.jsx has been updated to set the local proposal status to 'in_review' immediately after the API call succeeds, providing instant UI feedback.

Testing Blockage:

I was unable to run the automated tests (vitest for frontend, pytest for backend) due to a persistent issue with the run_in_bash_session tool. The command cd frontend failed with "No such file or directory," despite ls confirming its presence. This prevented me from fully verifying the changes automatically.

  • Does my code meet the quality standards for releasing packages?
  • Does the reviewer have all the information to validate the features/issues without too much research?
  • Does the customer who will validate the associated tickets have the information to do so without wasting time?

Issues to validate to close :

  • issue #

Processed issues to keep open or in progress:

  • issue #

Checklist:

  • Does the package check go local?
  • Does the CI pass?
  • Are the added / fixed features documented, tested?
  • Are the added features / solved problems briefly presented in the PR message?
  • Are the changes related to tickets / issues that I have listed in the commits and in the PR itself?
  • Are the tickets in "review" mode in the Project Tracking Board?
  • Does each ticket, if it is to be closed after acceptance of the PR, contain a comment that tells how to validate it?

Merge request reports