Description
There are unnecessary repetition of same logic checks in Order update API with subtle changes. It is checked 8 times, 8 times, that a field being updated in an order is allowed or not. It becomes impossible to update any logic and not lose track of why is this branch being checked and why is this in else block.
There is a branch for order made in ticket section, there is a branch for order made in public section. There is a branch for admin, there is a branch for organizer but not admin, then the same branch is repeated if you have organizer access 🙄. Why so many branches? Ideally there should have been a separate admin API which allowed to edit various parts of order and its use would have not been impacted normal API use case. Now, I don't understand which branches hit for normal use case and any fix I will make will break the admin API. Both of these have entirely different uses, but are unnecessarily crammed into 1 function (because jSoNaPi doesn't support more than 1 URL for 1 resource) which has resulted in insurmountable bugs.
A user can PATCH attendees of an order after its creation. So it can simply, create an order for 1 free ticket and then create dummy attendees with business and premium tickets. No order amount will be updated and it will just be bought for free.
Logic check for fields should be looped over only once and all necessary checks must be done then and there with proper comments
Creating an API from a backend project is not a small task, and separating frontend and backend from a project has same cons as breaking up a monolithic service in microservices. Microservices come at a great cost of increased attack surface because you are exposing code execution to the world, thus API design needs to carefully reflect what happens when a resource is deleted/updated/created. It is not as simple as creating a table and exposing a CRUD API to it and say do whatever you want. If it was still a server-side rendered project, these mistakes would at least not have made it vulnerable at the hands of external users. Providing an API or creating an API first project is not so simple, and shouldn't be done when there are just 1-3 people working on the project.
Right now, my goal would be to disallow any improper updates of the order, even if it breaks admin order creation panel. We'll take that as a secondary priority and only add features that make sense(placed order creation/cancellation) instead of exposing a glorified ORM over network which can do any arbitrary change, even for super admins.
Metadata
Metadata
Assignees
Type
Projects
Status