Document editing permissions

[jeddai]

The edit endpoint is currently open to any user. This feature would enable users to share document editing permissions with other users, but it would be an opt-in setup instead of it being open with no option to disable it.

• Currently, the API is designed so that if another user accesses an edit url that does not belong to them they can still edit the document and it will add them as an author.

---

• Moving forward, if you access an edit url and you are not one of the document's authors, you will get a 403 page that says you don't have edit access to that document.
• If you as the author want other users to be able to edit some of your docs, you can add authors to a document via the metadata pane (using their username).
• A warning would say that collaborative editing is in an interesting state and to make sure to save the document offline somewhere
• Document version in the database would be incremented on each save
• If the document version being saved is lower than the document version in the database it would prevent the save and show an error

[G-Ambatte]

If you as the author want other users to be able to edit some of your docs, you can add authors to a document via the metadata pane (using their username).

There's some good conversation in the Gitter developer chat, but the short version is that adding an author should generate an invitation which must be accepted by the new author BEFORE edit access is provided. However, this then is open for abuse (e.g. harassing a particular user via invite bombing), so some form of invite blocking needs to be in place prior to this being open to the public. I believe that this probably needs the UserInfo system in place to record the blocking preferences.

[calculuschild]

However, this then is open for abuse (e.g. harassing a particular user via invite bombing),

This can all be avoided by letting users handle the invites externally (Hey Joe, I added you as an author to the brew. Here's the edit link so you can accept: homebrewery.com/edit/buh). I think we can assume if users are collaborating on a brew, they also have some other means of contact. I.e., we don't need to "generate an invitation", but simply mark the user as "invited" so they have permission to access the edit link if they choose.

A spammer can't "invite bomb" a user if the Homebrewery doesn't send any messages based on other users' actions.

[G-Ambatte]

mark the user as "invited" so they have permission to access the edit link if they choose

I like this approach.

"Hey Joe, I added you as an author to the brew. Here's the edit link so you can accept: homebrewery.com/edit/buh"

We could probably launch a "Copy invitation text to clipboard?" window if we wanted to get really user friendly, so there's less opportunity for human error.

[ericscheid]

Side note: if an author is added via invitation to a brew, their name should not yet appear in the div.brewItem.brewInfo until they accept that invitation.

Otherwise y’all gonna be co-signatories on my latest brew “Pineapple on Pizza Is Delicious — A Manifesto”. And I won't be telling you the edit link so you can't remove yourself either. Bwahahahah.

[jeddai]

Re-starting on this work. Planning to break it out into multiple PRs, here's how I was thinking of breaking the work down:

1. Disable editing a document on which you are not an existing author. (403 error)
2. Add schema value for owner and make it default to the author in the 0th position
   • Would also require that if the owner deleted a brew and there were additional authors, the next 0th author would become the new owner
3. Multi-part for inviting authors
   • Add schema value for invitedAuthors
   • Update UI to make authors editable
   • Add UI -- when opening up edit for a brew you are an invited author on, open the view route and give the user the option to accept the invitation or decline
   • New authors go into the invitedAuthors array on save
   • Authors other than oneself can only be removed by the owner
   • Authors can remove themselves

[calculuschild]

Looks good. I would add that editing the authors via the UI should give some visual indication who is the owner, who are full authors, and who is just invited (and not yet accepted). Perhaps via color to start, but maybe a small hover tooltip as well.

Also, should we validate usernames when adding an invite? To avoid adding "calculuschiiild" as an author and when I try to accept the link nothing happens.

[jeddai]

The initial thought with invitedAuthors was to have it not be visible in the UI at all, but maybe it should be visible when you're editing the doc and only authors is visible when viewing?

[calculuschild]

Yes. Invited Authors should be visible to the owner (and other authors? I guess whoever we decide has permission to add invited authors). But not visible to anyone else.

[calculuschild]

By the way, assuming you will reuse the StringEditor UI from the Tags, feel free to build on top of the tags PR, since it should be merged before this is finished.

[ericscheid]

PR #2561 does almost everything discussed earlier. What it doesn't do is facilitate an author removing another author.

[ericscheid]

The remaining functionality has been raised in it's own issue now.