Store presets in db

[gmaclennan]

iD Editor uses JSON presets to define a UI for categories of features to map, which symbol to use, and which fields to show, and how these map to tag key-value pairs.

We currently maintain these as a separate repo and build them into a single JSON that iD can use with id-presets-builder and import that into Mapeo by bundling the presets and the translations file with mapeo-settings-builder and then manually importing this file https://github.com/digidem/mapeo-desktop/blob/master/browser/main.js#L70-L84 and https://github.com/digidem/mapeo-desktop/blob/master/lib/user-config.js#L49-L62

We should store these presets in the DB and sync them. In the future users should be able to update presets themselves, but I think we need for an admin override. Dealing with forks of presets starts to get really complicated for the user to understand, so I think we should have a fork/conflict resolution method for this.

[hackergrrl]

In the future users should be able to update presets themselves, but I think we need for an admin override.

Can you elaborate on this? I could read this as meaning, local edits are doable by anyone, but if an admin pushes out a new version of the presets.. it overwrite any changes they made? Curious what you were thinking (y'know, 5 years ago :P).

[gmaclennan]

Ha! Yes, that was a long time ago! I'm thinking that changing presets should be restricted to an "admin" group, but it will likely need to be more than a single person, so that does introduce the possibility of conflicts (two admins edit the presets). We still need to figure out how to determine an "admin" in a de-centralised system. For something like this I think it would be enough to enforce the "admin" role at the front-end, e.g. anyone who is part of the project with raw access to the Mapeo Core API could theoretically edit a preset, but the UI only allows admins to do that. Similar to the way we restrict editing on mobile to observations you create - there is nothing in the backend stopping that.

[gmaclennan]

I've been thinking about how to implement any kind of admin / role in our db. One thought I had was that each device could just ignore any hypercore entries from devices that it does not consider an "admin".

[hackergrrl]

Similar to the way we restrict editing on mobile to observations you create - there is nothing in the backend stopping that.

I agree that starting here is simplest. The new invite flow for OTF incorporated an isAdmin bit I think, which could be stored locally on disk.

I've been thinking about how to implement any kind of admin / role in our db. One thought I had was that each device could just ignore any hypercore entries from devices that it does not consider an "admin".

Yeah. And then there's the Q of how to set who is an admin. I think materialized-group-auth captures this logic well.