Skip to content

fix: Address follow-up issues from user testing

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

Created by: Edouard-Legoupil

This commit addresses a list of follow-up issues identified during user testing.

Changes:

  1. Chat UI/UX Fixes:

    • Fixed the load_draft backend endpoint to return the proposal status, ensuring the UI updates correctly after submitting for peer review.
    • Hardcoded the "Geographical Scope" options in Chat.jsx as per user request.
    • Enabled vertical scrolling on the chat sidebar by adding overflow-y: auto.
    • Implemented the ability to revert proposal status from "in_review" to "draft", including a new backend endpoint for this purpose.

  2. Word Export Content:

    • Fixed the Word export to show human-readable names for Donor, Outcome, and Field Context instead of UUIDs. This was done by resolving the IDs in the backend before document generation.

  3. Peer Review Workflow:

    • Fixed the /review/:proposal_id screen getting stuck on "Loading..." by creating a new backend endpoint /review-proposal/{proposal_id} that properly authorizes reviewers.
    • Added a deadline feature to the peer review process. This included updating the database schema, backend endpoints, and adding a date picker to the frontend modal.

  4. Knowledge Card Layout:

    • Adjusted the CSS for the Knowledge Card screen to allow the form and content panels to utilize the full width of the screen, improving layout and readability.

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