home | prev | next

Accessing Data: Organizing Data Via Workspaces

As we have seen, the system works by:

  1. Defining (structuring) data
  2. Entering data
  3. Searching and using data

But a user cannot really perform these key functions (defining, entering, searching, using) unless that user has appropriate access to the system resources and functionality necessary to carry out those operations.

Before that can happen, a user needs to be able to access resources (data records, files, templates, types, etc.) and functionality (operations that work with those objects).

User access to such processes and resources is organized and configured using the system's workpaces, groups, and users.

Default User Workspaces and Permissions

When an account-holding user performs actions that create and use types, templates, or other system objects, these objects are stored and access, by default, in each user's private workspace.

By following this practice, the system assumes that:

  1. individuals can always access their data and associated functionality immediately; and that
  2. sharing of information or capability must first be explicitly enabled.
  3. system SuperUsers only have the right to create and modify sets of users, groups, or permissions.
  4. all users, within the limits of their defined permissions and groups, may freely create as many workspaces for as many other users as they would like.
  5. the workspaces are the means by which access control is organized to the resources and functionality of the system.

How to Organize and Provide Access to Resources and Functionality

Each organization using the MDCS may wish to organize and define various workflows which may require different indviduals, often performing different roles, wherein each role may have different needs are restrictions governing what they can do, access, share, etc.

How Permissions, Groups, Users, Workspaces, Resources, and Functionality Fit Together

These restrictions express certain permissions which are defined by system SuperUsers in the groups (which may be thought of, merely, as being groups of permissions to perform various application operations).

Workspaces provide a way to link together whole sets of users (sometimes individual users, sometimes sets of one-or-more users) who have permission to perform certain functions (permissions). These functions are the basic capabilities which an individual or group use to specify overall workflows, processes, which govern what individuals can do on the system, what information they can share, and with whom.

Example Use Case: Ability to Allow Arbitrary Account Holders to Access Records

In practice, any possible process that a system's users might like to execute/express in terms of performing operations on system objects, can be a potential workflow.

At this point, we will merely highlight an important use-case wherein users of a systems need access-control configurations that can support enable arbitrary account holders in accessing and searching the data.

There might be cases wherein a users of a given system might wish to implement a kind of publishing and verification workflow.

Such configurations would require permissions, groups, capabilities, workspaces, users, around resources which could support workflow operations and rules such as:

  1. Be able to input, edit, and share data exclusively within a small, trusted "working group" until it has reached some agreed-upon publishable status.
  2. Various Users might be given different roles/access depending on whether they are, for example, an experimenter, an evaluator/tester, etc.