Created DBUser API.md, edit User Management.md as well, sync both

Requirements/User Management.md

@@ -20,21 +20,26 @@ especially our roles, and those will not be found in other system. There is not
 user profiles. We might want their social networking profile, but social networking is not a core function of
 SNAC.
 
-By default users can't do anything that isn't exposed to the non-authenticated public users. Privileges are
-added and users are given roles (aka groups) from which they inherit privileges. The authorization system is
-involved in every transaction with the server to the extent that every request to the server is checked for
-authorization before being passed to the code doing the real work.
+By default, the lowest privileged users can't do anything that isn't exposed to the non-authenticated public
+users. Privileges are added and users are given roles (aka groups) from which they inherit privileges. The
+authorization system is involved in every transaction with the server to the extent that every request to the
+server is checked for authorization before being passed to the code doing the real work. (Every request is
+also checked for authentication as well, naturally.)
 
 The Linux model of three privilege types "user", "group", and "other" works well for authorization permissions
-and we should use this model.  "User" is an authenticated user. "Group" is a set of users, and a user may
-belong to several groups. In SNAC and the non-Linux world "group" is known as "role", so SNAC will call them
-"roles". "Other" privileges apply to SNAC as public, non-authenticated users, although we don't really have
-"other", and the "researcher" role applies to public users.
-
-Users can have several roles, and will have all the privileges of all their roles. Role membership is managed
-by an administrative UI (part of the dashboard) and related API code. User information such as name, phone
-number, and even password can also change. User ID values cannot be changed, and a user ID is never reused,
-even after account deletion.
+and we should use this model, albeit somewhat simplfied.  "User" is an authenticated user. "Group" is a set of
+users, and a user may belong to several groups. In SNAC and the non-Linux world "group" is known as "role", so
+SNAC will call them "roles". "Other" privileges apply to SNAC as public, non-authenticated users, although we
+don't really have "other", and the "researcher" role applies to public users.
+
+Each feature has a list of one or more authorized roles which may access that feature.
+
+Users can have several roles, and will have all the privileges (access to features) of all their roles. Role
+membership is managed by an administrative UI (part of the dashboard) and related API code. Our system allows
+access to every feature associated with any user role. (Just an aside: some high-security systems restrict
+access to the least privileged role; like Linux, SNAC has a different model.) User information such as name,
+phone number, and even password can also change. User ID values cannot be changed, and a user ID is never
+reused, even after account deletion.
 
 We expect to create additional roles as necessary for application functions.
 

Specifications/DBUtil API.md

@@ -11,6 +11,32 @@ There is an interactive schema web site: [Schema web site](http://shannonvm.vill
 [New DBUtil and initialization](#new-dbutil-and-initialization)
 
 
+### Notes on undelete
+
+Undelete is not currently implemented. There is a function clearDeleted(), but it is almost certainly is not
+quite right, and we need agreement on how to call it.
+
+As of Mar 10 2016 we have functioning object operation via setOperation() and getOperation() with valid
+operations insert, update, delete. In this new world, undelete should be yet another operation, and should be
+integrated into the existing operation code.
+
+There are two problems:
+
+1) delete and undelete are different for constellation vs component
+
+2) it would be wrong for undelete to incorrectly undelete a component that was deleted before a constellation
+was deleted
+
+Issue (1) is typical for delete, and we need undelete code that is symmetrical with the delete operations.
+
+Issue (2) is interesting. If a constellation is being undeleted, we should not also apply the undelete
+operation to each component. Delete of a component is granular and undelete should be granular in the same
+sense. That is: delete of a component happens independently of all other operations.
+
+Likewise, constellation level delete should not allow component operations, thus it is probably best that
+constellation delete not traverse the components. Likewise, constellation level undelete should only undelete
+the constellation, and not traverse the components doing any operation, especially not component undelete.
+
 ### New DBUtil and initialization
 
 When creating a DBUtil object, DBUtil currently calls $this->getAppUserInfo('system') to determine the user id
@@ -85,7 +111,7 @@ $cObj = readPublishedConstellationByID($mainID);
 
 // public function, return the list of constellations I'm editing
 // uses $this->appUserID in the DBUtil object
-$cObjList = editConstellationList();
+$cObjList = listConstellationsLockedToUser();
 
 $status = 'locked editing';
 $newVersion = writeConstellationStatus($mainID, $status, 'optional arg, version note');