ispp-g5 / nexong_backend Goto Github PK

Implement the basic authentication feature for the backend project, taking into consideration the next week's future integration with an authentication framework. This should include the login and the register method.

Check if currently all the models as well as the serializers are working as expected. For example, a birthday cannot be 12/12/2030, or you cannot create a second lesson event of the same lesson if both of them collide. Also, this task should check the general state of the models, and that the business logic is working as expected in the requirement document.

After the meeting with our client, some old requirements have been changed and new ones have been introduced. Read the requirements sheet to update your knowledge.

It is necessary to implement proper password security for the authorisation feature, currently, it consists of plain text. The password should be correctly encrypted in the database, and it should be nearly impossible to obtain it back if the DB is stolen.

Create a CSV, a PDF and an Excel of the selected data of the backend giving also the option to download the related files in a zip/rar or accessible via URL to properly see them in the exported documents.

For this task, it is necessary to take the same structure/solution as the task developed in the week before.

Add this feature and also QuarterMarks crud

Along the week 7, some minor changes have been made to the db. It is expected that the populate will now be either incomplete or non working. The populate.json file shoud be updated so that it can continue tu be useful.

Educator, Partner, Volunteer and Family are derived from User. Therefore, if you do a GET on an educator with id 1 it should return educator with id 1 and the user that has the FK of educator id 1. If you do an operation on Educator, Partner, Volunteer and Family it should also be done on User.

And fix User CRUD.

Create a CSV, a PDF and an Excel of the selected data of the backend giving also the option to download the related files in a zip/rar or accessible via URL to properly see them in the exported documents.

For this task, it is necessary to take the same structure/solution as the task developed in the week before.

Implement middlewares: What can an admin user account do? Which data can the admin change and see and have access to, and where can do a GET, POST, PUT, or DELETE occur?

Describe the bug
There is a validator of another class in the serializer of meeting. It must be removed in order to work on meetings.

To Reproduce
Steps to reproduce the behavior:

1. Go to /api/meeting and recieve an error because the validator is not correct for this class

Expected behavior
Standard behaviour of an API class

Download files from the backend. And fix some populates issues

Implement middlewares: What can an educator user account do? Which data can the educator change and see and have access to, and where can do a GET, POST, PUT, or DELETE occur?

For this task, it is necessary to take the same structure/solution as the task developed the week before.

Now if you upload a file to the DB, the names stay the same. What happens when the backend gets 2000 files? Probably some names will collide. The plan is to implement a name and date system for the names of the files. The backend is responsible for change when a new file is uploaded.

Also, it should include a new table with the documents required for the homepage.

Meeting table alongside UserHasMeeting

CRUD operations and relations

Include a procedure to send an email after the registration process to verify that the user has registered in the application. This should include a new user model that reflects this verification and validation.

Implement middlewares: What can a student account (managed by the family, of course, only in the case it is not linked to it) or a family user account do? Which data can the student/family change, see and have access to, and where can a GET, POST, PUT or DELETE occur?

For this task, it is necessary to take the same structure/solution as the task developed the week before.

Create an extended version of the current populate for the database.

Create a /docs endpoint in the backend application (it can have another name rather than "docs", but it should be related). This endpoint should contain the swagger documentation of the entire backend. For the documentation, you should implement it using Swagger (https://swagger.io/). Still, try to keep the repository as well as the documentation organised and clean, for that reason consider creating a folder containing all of these.

Develop a sandbox payment method as a new table in the model called "Punctual donations with card" or "Telematic Punctual Donations". It is recommended to use the platform "Stripe".

https://www.youtube.com/watch?v=rKD5bhoTeFw

The names in the documents model are incorrect.

Beware of dependencies: Educator and Student

users in the populate are missing 2 attributes: first_name and last_name

The admin authentication is required to access some POST, PUT and DELETE methods. To give a first usable API, it is essential to remove the current authorisation of the deployed API to be usable for the frontend without the login process.

Create a CSV or a PDF of the selected data of the backend giving also the option to download the related files in a zip/rar or accessible via URL to see them in the exported documents properly.

The documents should be accessible using /API/export/type/document
The URL must accept a query or the method should accept a body to establish a range of values or a sorting method.

Right now, the README of the backend repository is outdated. It needs to be updated so frontend developers can use the backend smoothly.

Remove the default setting of SQLite to PostgreSQL

Implement middlewares: What can a volunteer user account do? Which data can the volunteer change and see and have access to, and where can a GET, POST, PUT, or DELETE occur?

For this task, it is necessary to take the same structure/solution as the task developed the week before.

Mockup data for the frontend

Implement the restrictions. The maxCapacity should be higher or equal than the attendees etc.

Create a CSV, a PDF and an Excel of the selected data of the backend giving also the option to download the related files in a zip/rar or accessible via URL to properly see them in the exported documents.

For this task, it is necessary to take the same structure/solution as the task developed in the week before.

Event table alongside UserHasEvent

Choose an authentication system for the backend to manage the logged users. The current options for this system are:

• Auth0
• OAuth
• Default one

The chosen system must be consensual and chosen according to requirements. Other systems can be proposed also if any of this fits in NexONG.

After the decision of the authentication system, it should be implemented in the app. Note that if the chosen system lacks social account support, the integration should be done manually.

Finally, it is required to integrate at least the Google Register and Sign-in method for the project.

Beware of dependencies, also this in the db translates to CRUD of StudentEvaluation and LessonEvaluation.

Relational model diagram for the PostgreSQL Database

Describe the bug
Right now there is a duplicated endpoint in src/urls.py because of a merge mistake. This can cause errors in the application.

Implement middlewares: What can a partner user account do? Which data can the partner change and see and have access to, and where can do a GET, POST, PUT, or DELETE occur?

For this task, it is necessary to take the same structure/solution as the task developed the week before.

How do you manage the documents like PDFs in the DB? Investigate the options. Create a new table with the server route to the document?

This issue consists of changing the current donations export feature to include punctual donations when the donations are exported. This should be reflected as a new column in the donation export that points out whether the donation is a registered user or a punctual donation.

It will also be great to include a last row only in the donations (not punctual), as a sum of all the donations of the table (only in the PDF).

It should be in App Engine