Closed nadrummond closed 1 week ago
Note on the above, as we will also be allowing people to edit team pages it maybe makes sense that we don't put these routes under pages, but instead a more generic content API under crowd funding so they can be shared between the teams and pages frontend editors.
The specific endpoints under the pages (or teams route) should be operations against the entity, e.g. /close, /open, /addPage, /editAllocation etc.
As the editing of pages will take place via JavaScript we need to implement an API for storing these changes in the Umbraco content tree.
The APIs will need to be authenticated which means using MemberAuthorize but also, each page is owned by one or more members so we need to add our own additional authorization filter to make sure the member making the request is listed on the page as owning it.
As per the design shown below editing a page involves opening a modal of a certain "type" such as textbox, rich text, image cropper etc. It seems to make sense therefore that our endpoints are 1 per type to match this. So, for example we might have
and also
and
Essentially the frontend developers will code up 1 modal per type of edit component and when it is invoked the two parameters that are supplied are the pageId (Umbraco content key) and also the name of the property to persist the value into.
We should be resilient against people posting garbage values for the property ID or payload, especially as this is a public site.