API:s for the new front-end

[ankurr0y]

Description of the Change

Added APIs for several models

Feedback needed

Permission for each API and which REST calls they should have (GET, POST, PATCH, PUT, DELETE) along with permissions for each REST call.

[ludvigalden]

Reasons for these changes? Committed by mistake?

[ludvigalden]

Hi Ankur, why is the commit message so long? Feel free to put any comments in the pull request, right here.

The only things that should be writable in these API:s are things that are editable on apply.utn.se and relating to one's own member profile details. I believe that would be one's own involvement applications, event applications, and event tickets. You should alao only be able to view your own member details, applications, and event tickets. Is that clear enough?

[ludvigalden]

Regarding the ticketing system, our team and level of production is small enough for us not to need one. The scale is perfectly manageable without any system that would leas to too much abstraction and cost us time that could be spent better.

[ankurr0y]

Adding the Role thing only for posterity's sake, everything works through position and not role according to the way that the data model is designed.

[ankurr0y]

The read is only for applicants on their own stuff. The write I will create separately in a moment. Also covers user profile

[ankurr0y]

Now, applications are only CRUD if you are the applicant

[ankurr0y]

But test it in a test environment a couple of times

[ludvigalden]

Here are some things that come to mind when looking at the committed code.

Teams

• You should not be able to edit, create or delete teams.

Roles

• You should not be able to edit, create or delete roles.

Positions

• You should not be able to edit, create or delete positions.
• When querying positions, expanded role and team objects are included in the response.

Application

• You should only be able to create applications for yourself and if the end time has not passed.
• You should only be able to view your own applications.
• You should only be able to delete applications with draft or submitted status that are your own.
• You should only be able to edit applications with draft status, but not edit the status or position, and only if the end time has not passed.
• When querying applications, expanded position, role and team objects are included in the response.

Events

• You should not be able to edit, create or delete events.
• When querying events, expanded costs as well as a thumbnail image URL are included in the response.

Costs

• You should not be able to edit, create or delete costs.

Event Tickets

• You should not be able to edit, create or delete event tickets.
• You should only be able to view your own event tickets.

Event Applications

• You should only be able to view the event applications that apply for your own event tickets
• You should only be able to create an event application if the event application end time of the event has not passed.
• You should only be able to create an event application for yourself.
• You should not be able to set the "ticket" of the event application.
• You should only be able to create or delete event applications.

Participants

• You should only view, edit or delete the participants that that apply for your own event tickets.
• You should only be able to edit, create or delete participants for tickets that are not locked.

[ludvigalden]

@ankurr0y

I have pushed the data interfaces that the front-end expects now. You can find it here.

Also, you’re missing the csrf_exempt decorator for the API-routes.

We also need an endpoint for getting the authenticated user's Member object, such as /me.

[ludvigalden]

Why not use the same path with varying HTTP methods? GET for reading, POST for creating, PATCH for updating the passed properties (set to null if properties should be set undefined), and DELETE for deleting?

[ankurr0y]

Why not use the same path with varying HTTP methods? GET for reading, POST for creating, PATCH for updating the passed properties (set to null if properties should be set undefined), and DELETE for deleting?

PATCH and DELETE are too different from the other two, needed to differentiate permissions, serializers and querysets for them. So they are separate.