Skip to content

Back cdr : Endpoint to get total of validated payments - #1028

Open
Bombefire wants to merge 12 commits into
mainfrom
total-purchase
Open

Back cdr : Endpoint to get total of validated payments#1028
Bombefire wants to merge 12 commits into
mainfrom
total-purchase

Conversation

@Bombefire

Copy link
Copy Markdown
Contributor

Description

Summary

Adding the endpoint for Enceladus to have the total payment done in the CDR and have the total of purchase that have been validated by the sellers.

...

Issues/PR dependencies

A futur PR in Enceladus will come to make use of this endepoint

Issues to be resolved

Required PRs

Changes Made

  • ...
  • ...

Additional Notes

Classification

Type of Change

  • 🐛 Bug fix (non-breaking change which fixes an issue)
  • ✨ New feature (non-breaking change which adds functionality)
  • 🔨 Refactor (non-breaking change that neither fixes a bug nor adds a feature)
  • 🔧 Infra CI/CD (changes to configs of workflows)
  • 💥 BREAKING CHANGE (fix or feature that require a new minimal version of the front-end)
  • 😶‍🌫️ No impact for the end-users

Impact & Scope

  • Core functionality changes
  • Single module changes
  • Multiple modules changes
  • Database migrations required
  • Other: ...

Testing

  • 1. Tested this locally
  • 2. Added/modified tests that pass the CI (or tested in a downstream fork)
  • 3. Tested in a deployed pre-prod
  • 0. Untestable (exceptionally), will be tested in prod directly

Documentation

  • Updated the docs accordingly :
  • " Docstrings
  • # Inline comments
  • No documentation needed

@codecov

codecov Bot commented Jul 29, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 40.74074% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 51.31%. Comparing base (4379a3d) to head (cfd70c4).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
app/modules/cdr/endpoints_cdr.py 40.00% 9 Missing ⚠️
app/modules/cdr/cruds_cdr.py 36.36% 7 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1028       +/-   ##
===========================================
- Coverage   85.06%   51.31%   -33.75%     
===========================================
  Files         220      220               
  Lines       16248    16288       +40     
===========================================
- Hits        13821     8359     -5462     
- Misses       2427     7929     +5502     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

select(
func.sum(models_cdr.Payment.total).label("total"),
).where(models_cdr.Payment.year == cdr_year),
)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we select all values then sum them in python instead? (asking because I genuinely don't know)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From memory summing with SQL is always faster then taking the data and doing operation independently

Comment thread app/modules/cdr/cruds_cdr.py Outdated
Comment thread app/modules/cdr/cruds_cdr.py Outdated
Comment thread app/modules/cdr/cruds_cdr.py Outdated
]


async def get_total_payment_types(

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

get_payment_total_by_type maybe ? This crud kind of bothers me, nothing is wrong but I feel like we aren't doing anything like it anywhere else and there may be a reason (what I mean is for example that you are using a schema which wasn't meant for this kind of data for example... maybe what would be more usual would be to have and endpoint to get a total for a specific type and let the front ask for each one, or let the front do the entire computing, idk and I need a second opinion on this)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will it not pose a problem, if supposedly need to add a new form of payment, if we have to call for each type of payment ? You can argue that we have to hard code each new form of payment but it just add a new layer of complexity for this recurrent problem.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, you'd just need a for loop, it would without hard coding anything either way ¯\_(ツ)_/¯ I just find it kinda weird myself, but if I'm the only one, it's fine

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand what you are suggesting : use a crud to get all the sellers/types, make a loop out of it where you get the total for each seller/type in the level of the endpoint. And after that, which schema do you send it to the front?

Comment thread app/modules/cdr/cruds_cdr.py Outdated
Comment thread app/modules/cdr/endpoints_cdr.py Outdated
Comment thread app/modules/cdr/endpoints_cdr.py Outdated
Comment thread app/modules/cdr/endpoints_cdr.py Outdated
Comment thread app/modules/cdr/endpoints_cdr.py Outdated
Comment thread app/modules/cdr/endpoints_cdr.py Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants