Map locking to prevent random edits or vandalism

[fiestin]

solving the problem of random edits to a map that damage the data created. thinking about creating a system for editable/non-editable in maps, but also, for longer term planning, desgining the ability to send a link to the map that embeds edit/view options for users.

[btbonval]

Weird, I thought this was already a ticket. We must have discussed it on a list at some point.

Google has a neat way of handling this. In order to share an editable document with others, you can choose to share a unique link. Of course that link cannot be controlled, so if it is intercepted or put in the wrong hands, anyone can edit the content. However, it offers the advantage of anonymous user edits as long as the people with the link can be trusted.

I'd say an author can make a map public (allows anonymous users to write) or controlled (read only unless the user has a special link).

This would work much like the password reset link with all the junk at the end being a random string.

[btbonval]

Do signed in users always get the ability to edit, or should there be an option to make maps non-editable for signed in users as well?

[fiestin]

you can edit maps without being signed in. would be good to choose between
anonymous or logged-in contributors for each map you create. Yes, I was
also thinking about the google doc technique.

[jywarren]

Hagit was moving this over from jywarren#149 -- This has seen various discussions and issues; it's important to distinguish between:

a. locking images temporarily, which is currently the case as of #33 for any newly-opened map
b. locking permanently, perhaps by only allowing the original author to edit an image

and also between

1. locking a whole map to edits
2. locking individual images

Hagit:

1. Do you think permanent image locking is something we should allow?
2. Would it be allowed on map creation?
3. Would it prohibit new images for that map except by the author, or would it only disallow editing of existing images?
4. Would it prohibit new images from anonymous users or from everyone? Or both?

Just trying to break up this request into its parts, thanks so much Hagit for your debugging help!

[jywarren]

Note to self: locking images can be done on this line: https://github.com/publiclab/mapknitter/blob/master/app/views/layouts/knitter2.html.erb#L165

Locking new uploads would be a little more involved; we'd have to put a flag and maybe initializer function in the upload.js script as well as change the interface to hide buttons and so forth.

[fiestin]

Recap email responses:

1. Registered users will be able to lock an entire map to edits except to other registered users
   1b. an edit log would be nice, it could be part of "edit history" with reverts, which would also solve this problem, but unfortunately it's quite a big project to do, so probably not immediately possible

Protecting edits is much more crucial than protecting map creation.
Requiring login for map creation is needed so that there's somebody who "has control over the map" otherwise there's no way to add permissions, because there would be nobody to use them. Based in input from organizers, the system wasn't designed to protect maps, it was designed to protect users' identities. But I think we've hit some difficult limits on that design priority, so we're re-thinking it here.

1. Locking a map would lock edits to existing images and prevent new images from being added. An unlocked map would allow edits and new images (I asked because this distinction is important for addressing the balance between protecting existing work vs. restricting contributions by new users; if we allowed new images, but not editing existing images, the model is a bit more complex, but less restrictive to new users)

the ones who are authorized can decide whether this should be added or not, and whether this anonymous person should be permitted to edit.

If users are anonymous, we can't give them any extra permissions, because we can't distinguish them from anyone else since we don't have a way to identify them. So locking would have to only allow registered users.

---

An edit history (as in this issue) really would give us less crude tools here; we could be less restrictive to new users because you could always revert their work, as in Wikipedia. But it's not a small project. Maybe it could be a GSoC project, or a fellowship?

[grvsachdeva]

Hi @jywarren, can you give an update regarding this issue?

[jywarren]

We'll be doing "image edit history" as part of this; i think it's mapped out a bit in #300, but we should expand it in a new issue!

That'll make things much easier. But true locking still faces the same basic issue:

1. default locked images would be great
2. but people doing group image work may want to share the task of distorting images, so they'd want to unlock
3. managing the locking/unlocking is hard

What if we adapted this to a new issue like:

Temporary unlocking of images for 1 hour or 1 day ? Maybe that'd help. We could even set a default that newly uploaded images are editable for an hour, and you can override it with a checkbox on upload?

[jywarren]

Summing up for 3.1 release (I hope!) we are aiming for the option at map creation time to have a checkbox that says Allow others to edit this map which is checked by default. All existing maps will have this checked by default.

However the author will be able to check/uncheck the box for existing maps they own (meaning not for anonymous maps).

This'll mean both a new access column in the Map table - a string - with values author or all (the default).

Later we may circle back to allow only edits by registered users as an additional option, registered.

We'll also need to modify the maps controller to redirect those without access to the new View page (in progress, by @cesswairimu in #777) with a flash notice This map may only be edited by its author.

Also a future plan - generating a unique token and allowing people to access the map if they have the special URL with the token, like https://mapknitter.org/maps/mymap/a1b2c3 -- this could have access set to token and a token field.