Using the MDCS
Once the system is installed, configured, and operational, it may be used by several types of general users. Each class of users is allowed access to certain functionality.
Anonymous Users
- Are not logged in to the system using an account (e.g., arbitrary users on the Internet who don't yet have a system account).
- May access content and functionality made public by the system.
Non-Administrative Users
- Can perform all actions allowed for
Anonymous Users
.
- Are logged in to the system using an account.
- Can access content and functionality they create or that is shared with them.
- Can organize access to that content through configuration of workspaces, ownerships, and permissions.
- Cannot access administrative functions.
Site Administrator Users
- Can perform all actions allowed for
Non-Administrative Users
- Can also access functionality provided by the
Administrative Dashboard
.
- Can configure the system for remote sharing and distributed search.
- Can directly import and configure system content from external sources – allowing development and incorporation of schemas, XSLT transformations, and custom input modules defined outside the system
- Cannot access Super User functions.
Super Users
- Can perform all actions allowed for Site Administrator Users.
- Can access functionality to directly manage users, groups, and external applications interacting with the system.
User Types
The restrictions applied to each class of users also determine what portions of the interface may be accessed.
The user interface is organized as follows:
- Non-administrative pages are organized with a navigation bar, body, and footer, each of which contains certain functionality.
- Anonymous users may access a subset of non-administrative pages.
- Site-administrative pages are organized around a vertical side-bar on the left of the page.
- Super-user pages are organized with functionality focused more towards the center of the page.
Access
Understanding that there are different user types which have different levels of access to system functionality leads us gently to the topics of:
Users
,
Groups
,
Permissions
, and
Workspaces
.
These concepts provide the basis for organizing and restricting access to data and functionality for individual users or groups of users according to how they are allowed to use the system.
The ways in which a given user is allowed to access and use the system may be based upon their role in helping to carry out particular workflows on the system.
Organizing Access Control
- All users having an account on the system (i.e., all user types except for
anonymous users
) have a private workspace assigned to them by default.
- Any records they create are automatically placed into their own private workspace, which is not accessible to other non-administrative users.
- When users desire to share access to files, they can create workspaces to support that sharing with approved groups of users and with desired permissions.
- Users assign these kinds of access controls when they create workspaces which can contain records.
- Administrative (or super-user) users can - for the overall system, or on behalf of particular user needs - define various groups of access permissons and can also associate these groups with various users.
- This design is very similar to the Unix design for groups, permissions, and access control to system objects and can support a wide variety of access control needs.
- This design is also based directly on Django's access control system.