Payment model

[jofmi]

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

Description

• Add a new module structs for types that are shared by multiple modules (i didnt call it types to avoid naming clashes with the built-in types module)
• Add database objects for Payment, PaymentType, and Account
  • Payment has a timestamp field for both date and time that is automatically filled
  • PaymentType and Account only have the field Name for now and will need more specifications in the future
• Add an endpoint api/payments that allows GET and POST
  • POST takes a special Type PaymentBatch that can create multiple payments. Payments are created together as a transaction. At the moment, it takes a list of payments in the following format: {"Payments":[{"Sender": 1, "Receiver":1, "Type":1,"Amount":1.00]}. This can be changed once we know what information we will get from the frontend.

Checklist:

• [x] I have commented my code (or ChatGPT did), particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings, neither in my IDE nor in my browser
• [x] I have added tests that prove my fix is effective or that my feature works

[jofmi]

Thanks for moving types to structs to have no naming confusion! I pushed two small commits. The first one due to an error I got after running docker compose build as shown below. The other commit is for the swagger. Maybe you review it now? A little inconsticency I see is our url convention as I have chosen in the beginning to use '/api/settings/' as it is shown in your collectivo API ;) But I would also prefer using '/api/payments' with no slash in the end. Do you know any conventions when to use what? The main code looks good. Especially the tests are nice!

Looks good!

Regarding the slashes i think both options are fine as long as we are consistent. In Django, the solution is to accept both, but I am not sure (yet) how to implement this in this framework.