Open keithamoss opened 3 months ago
Goal: Enable users to flexibly customise who can use their maps, schemas, and features. Inspiration: The flexible and abstract design we used for maps, schemas, and features.
Permissions will flow up from features => schemas => maps.
e.g. If a feature is set to private you won't be able to see it even if you have permissions through the schema or map
Ponder: What's the flow look like for H sharing the travel map with me Ponder: What does the permission logic 'Return the list of features for this map'
Consider Automerge as part of the implementation here: https://automerge.github.io/docs/quickstart/
Found via: https://tinybase.org/
Which may be worth considering as part of the offline support in future.
On serialising Django Permissions via DRF: https://stackoverflow.com/questions/62231851/how-to-pass-a-permission-via-django-rest-api
Features need created by field for future proofing
We use a boolean symbol field for "Added by K" now. H uses it to discover what I've added.
How would the discovery aspect work?
Would we be able to search by it?
Would we want to symbolise using the field?
Decision: Every action gets a permission associated with it (read/create/update/delete) that gets exposed via a UI in later stages. Earlier MVPs will have a simpler UI.
Decision: Some permissions will allow AnonymousUsers (like sharing a map publicly)
Use cases
Development plan
Basic use case
We use revisions to handle edit collisions between users rather than locks. This allows us to start implementing the offline/poor connection feature in a simple way.
All entities come with their
revisionId
. When an entity is saved we transmit therevisionId
with it. If that is not the current revision on the server (i.e. someone else has modified it since we got the last data update) then we either (a) merge the edits automatically if we can (i.e. there's no collision) or (b) prompt the user, show them the differences and ask them what they'd like to do.Automatic merging seems more in keeping with the Mapa ethos of getting out of the users way?
This could look like: User H and K load the map and have the same data, User K edits an existing point and changes Field 1, roughly at the same time User H edits the point and moves it. Because the users are changing different fields, User H's edit gets merged automatically. And maybe they get told or maybe they don't.
In a different use case, if User H had made a change to Field 1 it would have worked out we couldn't gracefully and. automatically merge the edits and told the user. This would be put the user into some sort of conflict resolution UI that appeared over the top of whatever bit of UI they were on. Hopefully this could be a generic bit of conflict resolution UI that could work for all entities.
Check this shape with H and discussion these outstanding questions.
Permissions levels
Features
Maps, schemas, et cetera
Full use case
Permission levels
Features
Maps, schemas, et cetera
Moderation
Light moderation could be built using a few separate features:
moderated === true
moderated
can only be set by Moderators and Editors'Adders' can then only add points to the map for fields they're allowed to edit. e.g. All fields except for
moderated
Or, alternatively, all fields are available to adders and editors and moderation is a specific new feature that is separate entirely to schema fields. Needs pondering. The generic shape of field-level permissions is in keeping with the generic shape of Mapa's other features.
For filters, we already implement a temporary and simple version of filters for the search interface. This would be extending that to something that allows one or more filters to be set and saved on a map.
Should the field-level permissions be attached to the map or the schema?
How would creators/moderators see a point in order to moderated it if the filter is hiding unmoderated points? I'm imagining they can click a link in an email to moderate it, or click a link to auto-approve it based on what's in the email, or login and go to into a 'moderation' view that shows the moderated points on the map and/or in a list.
As part of moderation, we'd somehow need to track information on who added the point e.g. name and email? That's easy if we're requiring them to login first...
But maybe we're allowing anonymous users to be Unauthorised Adders? Let's discuss - pros and cons both ways.
Does 'Read-only / viewer' mean public to any Mapa user or public anonymously? I presume the latter, to reduce the barrier to entry.
I guess maps would like to have vanity URLs
Check this shape with H and discussion these outstanding questions.