keithamoss
commented
3 months ago Design Document
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 Outline
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
Maps
- Who's allowed to see your map (Default = Private [No one, just me], Specific Mapa users, Any Mapa user, Anyone [Public, no Mapa account required])
- Who's allowed to suggest features to add to your map aka moderation (Default = Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to add features to your map aka unmoderated (Default = Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to do anything to your map except delete it e.g. edit and delete features (Default = Private [No one, just me], Specific Mapa users, Any Mapa user)
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'
Schemas
- Who's allowed to see features that are using this schema? (Default = Inherit from maps, Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to delete features using this schema? (Default = Inherit from maps, Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to change the symbols on this schema? (Default = Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to change the fields on this schema? (Default = Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to do anything to your schema except delete it? (Default = Private [No one, just me], Specific Mapa users, Any Mapa user)
Features
- Who's allowed to see this feature? (Default = Inherit from map, Private [No one, just me], Specific Mapa users, Any Mapa user
- Who's allowed to change the symbol this feature uses? (Default = Inherit from schema, Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to change the fields on this feature? (Default = Inherit from schema, Private [No one, just me], Specific Mapa users, Any Mapa user)
- Who's allowed to do anything to your feature except delete it? (Default = Inherit from schema, Private [No one, just me], Specific Mapa users, Any Mapa user)
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 therevisionIdwith 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 === truemoderatedcan 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
moderatedOr, 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.