Skip to content

Documentation
Documentation
Commit 8db4f154 by Tom Laudeman
Options

Align prose in DBUser and User management

parent 0f5a27e9
Showing with 48 additions and 45 deletions
Requirements/DBUser API.md
......@@ -53,28 +53,30 @@ to use SNAC. Members of the public are mostly identical to Researchers. The prim
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) |
| Publish | May approve constellation publication (editor) |
| Delete/embargo | May delete or embargo constellations (editor) |
| Propose delete/embargo | May propose delete or embargo |
| Ontology propose | May propose headings in ontologies, but cannot approve headings |
| Ontology approve | May approve ontology headings (editor) |
| Propose NACO | May create(?) NACO contributions, but not push(?) to NACO |
| NACO approve/finalize/submit | May approve NACO contributions (editor) |
| Enroll | May enroll new SNAC participants, create new users |
| Role assign own institution | May assign new roles for own-institution users |
| Role assign any institution | May assign new roles for any institution users |
| System administrator | Maintains server hardware and operating systems |
| Developer | Writes the SNAC application, a programmer |
| Web administrator | (duplicate? historical?) May perform admin tasks via the web interface |
| Database administrator | Create and maintain the SQL database |
| 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 |
| 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) |
| Publish | May approve constellation publication (editor) |
| Delete/embargo | May delete or embargo constellations (editor) |
| Propose delete/embargo | May propose delete or embargo |
| Ontology propose | May propose headings in ontologies, but cannot approve headings |
| Ontology approve | May approve ontology headings (editor) |
| Propose NACO | May create(?) NACO contributions, but not push(?) to NACO |
| NACO approve/finalize/submit | May approve NACO contributions (editor) |
| Enroll | May enroll new SNAC participants, create new users |
| Role assign own institution | May assign new roles for own-institution users |
| Role assign any institution | May assign new roles for any institution users |
| System administrator | Maintains server hardware and operating systems |
| Developer | Writes the SNAC application, a programmer |
| Web administrator | (duplicate? historical?) May perform admin tasks via the web interface |
| Database administrator | Create and maintain the SQL database |
| 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.)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment