More granularity for editor permissions

[akien-mga]

I'd like to have more options to define what editors can do, especially when using the "anyone can edit" option, which seems to make everyone admin (everyone has access to the full map settings and can even delete the map).

It would be nice if the editor role (or a new role if need be) would be able to edit the map (add/edit markers in existing layers, etc.) but not have access to the map settings, and maybe also be limited when it comes to deleting content (should not be able to delete layers for example). Ideally there should be granularity for all actions so that you can configure such a role yourself, but a preset with a good default configuration would be good already.

---

My use case: I want to make a map for all users and contributors of the @godotengine project to pin their location, to help organize local meetups and events. We're talking hundreds (possibly thousands) of people who need to be able to place a marker on the map, so I can't add them all to the editors whitelist manually, and thus need to use the "everyone can edit" option.

But as far as I can see, it means that everyone can decide to delete the layer with the data carefully input by hundreds of users, or even delete the map itself altogether, which is a big concern to me.

Note: I'm using the hosted http://umap.openstreetmap.fr instance, so it may be that such roles can be configured when doing one's own install but not on the aforementioned instance, in which case having our own hosting could be a solution.

[ADepic]

Yup. This is a killer feature. I would like to make a skycoin Miner's distrubution map using umap (the current one is made in Google My Maps), but since I cannot stop everyone from deleting work, I have to let the Google My Maps one stay for now.

[yohanboniface]

can even delete the map

This should not be the case. If so, it's a bug. In theory, only the owner can delete the map (not even the editors).

Ideally there should be granularity for all actions so that you can configure such a role yourself, but a preset with a good default configuration would be good already.

That's an option, but I'm not a big fan: this may easily be hard to use and hard to maintain.

(add/edit markers in existing layers, etc.)

A lot of the subtleties of the topic lay on this "etc.". Basically, as of today, the right management rely on resource + verb, where resource is Map or DataLayer, and verb is one of GET, POST/PUT/PATCH, DELETE. The first thing you can see is that there is no resource for a feature element, the smallest element is the DataLayer. Second thing is that basically we can allow reading but not editing or editing but not deleting a resource, but we cannot go into more granular level (like per property and such). So an option may be to define an intermediate open level where anonymous users could edit a DataLayer but could not delete it, and could not edit nor delete the Map. Still, one malicious user may empty a datalayer and then save it, which start to become tricky to prevent (one may do it for good, one may keep just one feature…). This also rise the question of the versions kept: as of today, we only keep X version per layer (10 by default). So again, one malicious user may hit the save button X +1 times to even delete the latest good version. And one more thing: for now, the frontend does not know anything about the permissions, apart a global on/off given by the backend for this specific user on this specific map. And then any save requested by the frontend for any resource is checked by the backend for the permissions. So if we'd go on the intermediate open permission level, we'd need the frontend to know which buttons/actions to show or hide.

[yohanboniface]

So if we'd go on the intermediate open permission level, we'd need the frontend to know which buttons/actions to show or hide.

Note: this will be easier once https://github.com/umap-project/umap/pull/583 is done.

[akien-mga]

This should not be the case. If so, it's a bug. In theory, only the owner can delete the map (not even the editors).

I'll admit that I did not test it as I don't want to delete my map, but when browsing a map while unlogged (even in Private Browsing mode), I still see those buttons:

Still as anonymous/private browsing user, I also have access to most other settings AFAICT, including some permissions management (but only limited to apparently adding editors?):

Basically, as of today, the right management rely on resource + verb, where resource is Map or DataLayer, and verb is one of GET, POST/PUT/PATCH, DELETE. The first thing you can see is that there is no resource for a feature element, the smallest element is the DataLayer.

Thanks for the details, that makes sense. It does indeed limit the granularity of permissions that could be offered, though what is doable with the current design might already be a nice improvement. Basically it would mean having per-map (and optionally per-layer) permissions of the type read/write/delete.

So the permissions matrix could be permissions[resource][verb] = {OWNER,EDITORS,USERS,INVITED,ALL} ("INVITED" would be users with a special "edit" URL, but not necessarily logged in nor whitelisted).

This also rise the question of the versions kept: as of today, we only keep X version per layer (10 by default). So again, one malicious user may hit the save button X +1 times to even delete the latest good version.

Indeed, the above matrix should be enough to give some level of confidence that users won't mess up the map, though a troll could still do some damage. Having more automated backups and/or an option for the owner to download the data locally would help further. Then it would be easy to undo vandalism by upload an older set of backed up data.

[yohanboniface]

or an option for the owner to download the data locally would help further

There is ;) The "umap" format in the download panel is a full map download, so you can restore the map on another instance or on a new created map for example.

[akien-mga]

or an option for the owner to download the data locally would help further

There is ;) The "umap" format in the download panel is a full map download, so you can restore the map on another instance or on a new created map for example.

Oh thanks, I had missed that panel. I had looked for download options but did not think to find them in the Embed panel. I'm not sure where would be a better location for discoverability though.

[yohanboniface]

I'd not propose the full matrix on the permission management form, but maybe something like:

## Who can see the map?
- only owner/only editors/everyone with link/everyone
## Who can edit the map settings (includes adding new editors and changing permissions)?
- only owner/only editors/everyone
## Who can add a new layer?
- only owner/only editors/everyone
## Who can delete a layer?
- only owner/only editors/everyone

Keeping as is for deleting the map or changing the owner: only the owner can do it.

(In this exercise, the "invited" option is left for a further step ;) )

Thoughts?

[akien-mga]

Seems good to me, though which of the "add layer" and "delete layer" permissions govern the possibility to edit a layer's contents?

My idea behind proposing per-layer permission management is that some use cases could have a set of layers managed by editors (so read-only to everyone) + one or more layers where everyone can add their own features. But what you outlined above would definitely be a good start already, and I agree with keeping things simple and wait for the more complex use case to present themselves (if at all) :)

[yohanboniface]

My idea behind proposing per-layer permission management is that some use cases could have a set of layers managed by editors (so read-only to everyone) + one or more layers where everyone can add their own features.

OK, missed that point: having one layer open and some others locked. Makes sense.

[ADepic]

There should be a option that only allows people to edit their own changes. Maybe this can be achieved by automatically assigning a new layer to each editor, but that would be super confusing.

The best solution it seems is to have a admin option that is: "Let editors add new items + modify & delete their own work - but keep those changes read - only for other editors" and if I were a editor I couldn't edit other people's stuff (unless admin of course).

Use Case: I would everyone to be able to pinpoint their approx location of their skycoin miner. Obviously they should not be able to change other's pinpoints.

[yohanboniface]

There should be a option that only allows people to edit their own changes.

There is no such concept of "work ownership" currently, and I don't see it as a simple feature to add sadly. The only item "owned" is the map, and this ownership extend to each layer inside it (and features does not even exist as separate objects for the backend).

I've thought about a concept of "map inclusion", where one map could include others maps layers (as remote data, so no editable), and maybe with an "opt in" mode where one may declare its map as included in another one, but I don't think this would scale to so many users.

Another option when you have this kind of audience: create an online spreadsheet where everyone enter their data + lat and lon and display it in uMap as remote data (with CSV format).

[VjeraTurk]

This also rise the question of the versions kept: as of today, we only keep X version per layer (10 by default). So again, one malicious user may hit the save button X +1 times to even delete the latest good version.

Do these restrictins also imply that no more than X people can edit map at the same time (each adding their own pin)?

[forteller]

I came here to ask for this exact thing. It doesn't have to be a lot of granularity to be a big upgrade from how it is today. Yes, allowing to add items, but not delete them, would be great. But as a first step just allowing to edit the map, but not to edit any settings would be a great start!

Thank you!