Align prose in DBUser and User management

Requirements/DBUser API.md

@@ -54,7 +54,7 @@ an account is a persistent dashboard.
 
 
 | Role                          | Role Description                                                       |
-|------------------------------+------------------------------------------------------------------------|
+|-------------------------------+------------------------------------------------------------------------|
 | Public HRT                    | No account, but may use HRT public interfaces to SNAC                  |
 | Researcher                    | May use the discovery interface and history dashboard, has an account  |
 | Create/edit                   | Create and edit constellations but cannot publish (contributor)        |
@@ -75,6 +75,8 @@ an account is a persistent dashboard.
 | Block upload                  | May do bulk uploads of EAC-CPF, finding aids, etc.                     |
 | Institutional reporter        | May run own-institutional reports                                      |
 | Super reporter                | May run any report                                                     |
+| Instutional affiliation X     | Affiliated with institution X.                                         |
+| Instutional affiliation super | Affiliated with all instutions, a super role (discuss?)                |
 
 
 
@@ -105,6 +107,9 @@ an account is a persistent dashboard.
 
 ### What data has to be stored for the user
 
+Accounts need an active flag. Deleted accounts might be kept inactive, in order to prevent accidentally
+creating an account wiht the same name at some future time.
+
 ### What data is bookkeeping
 
 ### Authentication login

Requirements/User Management.md

@@ -16,35 +16,33 @@ see how much work it was to support the various OpenID partners.
 ### Authorization
 
 Authorization involves controlling what users can do once they are in the system. That function is sort of
-more solved by OAuth or OpenID by sharing the user profile. However, SNAC has specific requirements,
-especially our roles, and those will not be found in other system. There is not anything we must have from
-user profiles. We might want their social networking profile, but social networking is not a core function of
-SNAC.
+more solved by OAuth or OpenID by sharing the user profile. However, SNAC has specific roles which will not be
+found in any other system.
 
-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.)
+By default, the lowest privileged users can't do anything that isn't available to the non-authenticated public
+users. Privileges are added and users are given roles 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.)
 
-### Roles analagouse to groups
+### Roles analagous to groups
 
 The Linux model of three privilege types "user", "group", and "other" works well for authorization permissions
 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.
+SNAC will call them "roles". "Other" privileges don't apply to SNAC. Non-authenticated users have the
+"researcher" role.
 
 ### Roles and privileged application features
 
 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.
+membership is managed by an administrative user interfac (probably part of the dashboard, or there will be a
+special admin 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
+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.
 
@@ -55,7 +53,7 @@ the case of reports, membership in an institution constrains the reporting. When
 may only choose from institutions of which they are members. Some reports may auto-detect the user's
 membership.
 
-By and large when we refer to "accounts" we mean web accounts managed by the Manager/Web admin. The general
+When we refer to "accounts" we mean web accounts managed by the Manager/Web admin. The general
 public can use the discovery interface without an account, but saving search history, and other
 session related discovery tools requires an account. It is technically possible to have a single session
 dashboard. Although that has not been mentioned as a requirement and is probably a low priority, it might be
@@ -66,14 +64,13 @@ almost trivial to implement.
 Every account will be in the "Researcher" role which has the same privileges as the general public, but with a
 TBD set of basic privileges including: search history, certain researcher reports.
 
-
 See the two tables "Role" and "User type" in the "DBUser API" documentation:
 
 [Role in Database User API](Requirements/DBUser API.md#roles)
 
-Remember: institutional affiliation roles aren't in the tables. There will be many of those institutional
-affiliation roles, and users may have zero, one, or several institutional roles that define insitutions
-with which the user is affiliated.
+Remember: institutional affiliation roles aren't all listed in the tables. There will be one institutional
+affiliation roles per institution. Users may have zero, one, or several institutional roles that define
+insitutions with which the user is affiliated.
 
 It is possible for an institutional administrator to also be a member of more than one
 institution. Institutional Admins have abilities:
@@ -96,7 +93,8 @@ Roles which may have zero or more institutional roles:
 - Researcher
 
 
-There are several dashboard sections:
+There will be several dashboard sections or dashboards. For more detail, see the dashboard requirements and
+specification. (link needed)
 
 - Standard researcher history
 - Standard user account management (password, email, etc.)