Skip to content

feat: Overhaul proposal and dashboard logic

Edouard Legoupil requested to merge feature/proposal-dashboard-overhaul into main_dev

Created by: Edouard-Legoupil

This commit introduces a comprehensive set of features and refactors the application's core proposal and dashboard functionality.

Key changes include:

  1. Relational Proposal Data:

    • Proposal creation now uses relational tables (proposal_donors, proposal_outcomes, proposal_field_contexts) instead of a single JSON blob in form_data.
    • The proposal creation form is updated to fetch and submit IDs for these relations.
    • Dashboard and review endpoints now use JOINs to fetch this relational data.

  2. Dashboard Enhancements:

    • Project cards on the dashboard now display the relational data (donor, country, outcomes).
    • A "Budget Range" field has been added to the project cards.
    • The project summary display is now trimmed to the first 5 lines.

  3. New Feature: Knowledge Cards:

    • A full implementation of the Knowledge Cards feature has been added.
    • Includes a backend API for CRUD operations.
    • The dashboard now has a "Knowledge" tab to display cards.
    • A new screen has been added to create new knowledge cards.

  4. New Feature: Metrics Dashboard:

    • A new "Metrics" tab has been added to the dashboard.
    • A backend API provides data on proposal development time, funding by category, and donor interest.
    • Includes filtering by user, team, and all proposals.
    • A new proposal_status_history table was added to enable accurate time-tracking between development stages.

  5. User Teams:

    • A team column has been added to the users table.
    • The registration screen and backend now support assigning users to a team.

  6. Dummy Data:

    • A seed file has been added to populate the database with a realistic dataset for testing and demonstration.
  • 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