Support all desired authorization options in submission database workflow

[ahayes]

Context

Currently Nunaliit has a pair of "database writing" code paths that an atlas builder can choose between when configuring an atlas.

The original path has client-side Nunaliit code submitting updates to couchdb on behalf of the user with the atlas design document validate-doc-update function validating the structure of the document as well as deciding whether the change should be allowed based on a set of rules. If a change is not accepted, an error is presented to the user and the proposed changes are not committed to the database. Rules were devised to allow non-authenticated users to contribute new documents to the database but the only layer that a document could be placed on was the public layer to protect the map unless the atlas builder wanted users to add to it. Authenticated users could essentially lock down changes to documents by adding them to non-public layers. Over time the validate-doc-update evolved but still has the original design that if you are not authenticated and authorized, you can't make changes other than adding documents without layers or documents with only a public layer. There is no way to propose changes to documents with this system. One other system designed at this time was the concept of approval for uploaded media. While it seemed reasonable to allow people to add documents to the database and put them on a public layer, the addition of documents with attached media was deemed potentially problematic so an uploaded media approval system and tool page was devised. This is still in place.

At some point user roles were introduced and some specific standardized roles were created for Nunaliit atlas users. <atlasname>_administrator is allowed to change any documents in the atlas database. Support was also added for roles that mapped to layer names such as <atlasname>_layer_<layername>. An administrator role was created for users who might administer multiple atlases in a single couchdb instance. At one point it was the role required to modify documents in the couchdb _users database. Something changed in couchdb 2.x to restrict the _users database to couchdb admin users. There was also some development of a "locked-down" atlas concept that required a user to have a <atlasname>_user role to be able to see the "Add Related [Document]" buttons and possibly other UI elements for adding and editing. Additionally, the concept of multiple public layers (any layer prefixed with public_) was added.

More recently, the concept of a submission database was developed. Choosing to enable it when configuring an atlas permits any authenticated user to go through the motions of creating, editing, and deleting documents on the client-side with the proposed document changes being stored in a separate submission database (by default named <atlasname>submissions at the time of atlas creation if the option was enabled. This document would either be auto-approved if the user making the submission had a role that would authorize it, or it would await review by an administrator. At around the same time, the user system was enhanced to allow for users to create their own accounts tied to their email addresses. The <atlasname>_vetter role was created to designate users who should receive email from the submission database system when new submissions were received that needed to be vetted and either approved or rejected.

The new submission system has worked well but does not support all the original authorization scenarios. In particular, the special functionality around public layers was not implemented. This issue has been created to track the effort to reconcile the capabilities and end up with the submission database system having all the features of both original systems as well as uploaded media approval.

Target Design

Below is a work in progress. I still have lots to do including some fact checking to do on current stuff and more to write up. Parking it here for now though.

Current & Proposed entities:

Special to couchdb document types:

• users
  • these are in a separate _users database managed by couchdb
• replicator
  • these are in a separate _replicator (or any db with a _replicator suffix) database managed by couchdb (as of version 2+ of couchdb)
• design
  • Nunaliit stores the client side application in these special documents inside the <atlasname> database.
    • _design/atlas
    • _design/site

Special only to Nunaliit document types and stored in the <atlasname> database:

• skeleton
  • atlas
  • navigation
  • module
  • schema
  • layer definition
• data
  • everything else

Roles:

• none
  • unauthenticated user
• ToU accepted
  • has an account and has agreed to most recent ToU if present
• atlas user
  • useful in locked-down atlases where an atlas builder wants to limit submissions to known users
• atlas layer editor
  • not authorized to add, edit, or delete documents unless role present for every named layer a document claims
• atlas editor
  • authorized to add, edit, or delete any non-skeleton document
• atlas vetter
• atlas administrator

Some overarching design goals for the authorization system in Nunaliit should be:

• Easy for non-technical users to contribute data to an atlas.
  • Optionally not require an account to create documents.
• Possible for an atlas builder to