Access control structure

[kmccurley]

The access control right now is that when a program is created, anyone can read the program but only the person who created it can update it. If another person opens the program and makes changes, it will be saved under that person's userid. This seems to confuse people since they are used to google docs. There are two things that we might want to add for access control:

First, the user may wish to keep the program from being read by anyone else. In my opinion the existence is OK to disclose in the list of programs, but opening the program could be protected by an ACL. There is also the question of what the default ACL should be (I would opt for readable). We could make the ability to lock it down in the metadata dialog, and make an "access" field in the programs table.

Second, in most cases there are several people who want to edit the program, and it makes sense for someone to share access to the doc with an email address. In my mind the way it would work is:

1. user creates the program, and goes to File to "share" access by entering an email address. This generates an email to the recipient with an auth token in the URL.
2. when the second user clicks on the link, the second user must authenticate themself to the database (iacrref,password) and then it updates the programs database to add the user as an editor. At this point either user could update the program. Unfortunately if user A has the program in memory and user B modifies it by writing back to the databse, we have no mechanism to update user A's copy. We could fix this with two mechanisms:
   • use a websocket to update the client whenever the backend version changes. This is basically how google docs works.
   • if a user tries to modify something but has an out of date version, it should reject the change and signal the user to reload the program (this is clumsy).
3. it's not clear if we should keep revision history so we can at least see what the other users changed. This opens up a whole can of worms for how to track changes (perhaps we should have an "undo" feature for all changes). In this case we would store every say into the database and use the ts field to sort out which one is most recent. This could mushroom the size of the database, though we could always limit the number of versions stored for each id.
4. it's not clear how to represent the ACL in the database. I propose we have another table called "ACL" that has the following schema:

CREATE TABLE ACL (id not null references programs(id),
                  email varchar(255) NOT NULL,
                  userid varchar(255) NOT NULL,
                  username varchar(255) NOT NULL,
                  token VARCHAR(255) NOT NULL,
                  UNIQUE(id,email));

The semantics of this table could become complicated with all the