Allow users to create/update presets on site

[bates64]

Currently, the process for creating presets requires forking this repo, editing backend code, and creating a pull request. If we put presets in the database and allowed users to edit them, that would make it easier and not require redeploys.

[ethteck]

Partially done in #897

[axel7083]

I took a deep dive into how presets are used, and here are the steps required to allow user to create/update presets

Adding owner foreign key to preset table

In a similar maner than scratch are storing the ownership, the preset table should add an owner column.

https://github.com/decompme/decomp.me/blob/ed910d70a609523a4087b4f13e61cf0213843ad7/backend/coreapp/models/scratch.py#L117

ℹ️ We would keep null for the system presets, being the one provided by the site, and not owned.

⚠️ I would not replicate the claimable mechanism of the scratches, where anonymous user could create presets, I would only allow authentificated user to be able to create presets, so we avoid the claimable stuff.

Updating permissions of the PresetViewSet

Currently the permissions are very limited, and only admins can create new presets.

https://github.com/decompme/decomp.me/blob/f61668a77b17ef5d4ffc15d14d1d15c7f66c8a5d/backend/coreapp/views/preset.py#L29

We would have to change this, to allow authentificated user to create (POST) and manage (PUT/DELETE) their presets.

ℹ️ This is not a difficult change.

Manage how presets are dispayed

Currently presets are included in the following endpoints

• /api/compiler
• /api/preset

But how do you filter the presets, does all user have access to all presets of everyone ? This has a design flaw, as let's say someone is creating 500 presets, user would have some issue finding the one they would probably expect.

We could for example, filter the presets, and only display the one by the system (without ownership), and the one of the user. But this would makes hard to share the presets. We could also imagine, that user should duplicates/fork presets of user, if they want to use them.

This is the point where I am not sure of the design to adopt.

Frontend

The dropdown should probably be migrated to some searchable component, since a lot of presets could be shown here.

Additional

I would after the table to add a UNIQUE contraint on the name to avoid confusion.

https://github.com/decompme/decomp.me/blob/c80abfaa0502018d15444aee6481cbb1978e80fe/backend/coreapp/models/preset.py#L10

[ethteck]

does all user have access to all presets of everyone ?

for viewing, I think this is absolutely fine as a first draft. eventually projects will contain presets, so that'll help more naturally organize them

UNIQUE contraint on the name

if you mean the name field of the Preset model, I am totally for that change. just checking since you linked to the platform field definition

Overall, this is an excellent comment and thank you for taking the time to consider everything. The only thing I think we're missing is the UI for creating / modifying presets. I imagine the modification could happen on the preset page itself. If you own the preset (are a site admin or are the user in the owner field for that preset), you can press a button to open a modal / show some new ui that allows modifying the preset.

I think we can mostly use existing UI elements for this, like the compiler options UI, in addition to maybe a couple new boxes / things for the fields we don't cover yet on the scratch options page.