About Users, Classes and Campaigns

joshuaselsky edited this page Mar 19, 2012 · 25 revisions

Users, campaigns and classes are the central entities that control access to ohmage.

The proverbial user is the person who can authenticate with the system and perform certain actions.

The actions a user can perform are defined by

  1. bit attributes on the user table
  2. the user's class role
  3. the user's campaign role

Creating Users

The admin role is the only role in ohmage that is allowed to create other users in the system. ohmage ships with a default admin account.

When a user is created, the following properties must be set:

  • username - must be between 4 and 25 characters and must contain at least one alphanumeric character; it may also include . _ @ + -
  • password - must be between 8 and 16 characters; must contain at least one lowercase character; must contain at least one uppercase character; must contain at least one digit; and must contain at least one of the following: , . > < [ ] ! @ # $ % ^ & * + - { } | :

When a user is created, the following properties may be set:

  • enabled - the default is true; if this is set to false, the user will not be able to login
  • can create campaigns - the default is false
  • make admin - the default is false
  • require password change on first login - the default is true

Note: we are currently implementing self-registration for our 2.11 release (ETA mid April 2012).

Creating Classes

The admin role is the only role in the system that may create classes. Classes represent a named group of users.

When creating a class, the following properties must be set:

  • class URN - a URN that must be unique to the ohmage instance; the typical syntax is urn:class:..., but any valid URN is allowed
  • class name - a descriptive name of the class, e.g., 'ADHD Pilot'

When creating a class, the following properties may be set:

  • description - a class description, e.g., 'The ADHD Pilot Class. Users will be asked periodically to play a 'focus game' on their mobiles and the results will be collated to quantify ADHD symptoms'.

After creating a class, users may be added to the class. A user can have the class role of privileged or restricted. The class role controls user permissions on classes and drives the creation of campaign roles when a class is added to a campaign.

Class Permissions

Operation Admin Privileged Restricted
Create Class anytime never never
Read any Class Properties anytime anytime anytime
Read a List of Logins For Classes that You Are a Member of anytime anytime anytime
Read a List of Logins For Classes that You Are Not a Member of anytime never never
Read a List of Logins, Roles and Personal Info for Classes that You are a Member of anytime anytime never
Read a List of Campaigns Associated to Classes that You Are a Member of anytime anytime anytime
Read a List of Campaigns Associated to Classes that You Are Not a Member of anytime never never
Add or Remove Users from a Class that You Are a Member of anytime anytime never
Update Class Name or Description; Change User's Class Role anytime anytime never
Delete Class anytime never never

Creating Campaigns

A campaign (we don't like the name "campaign" either) consists of an XML configuration, which defines surveys and prompts within those surveys. The XML configuration must also define a unique campaign URN and a campaign name.

Users that have the can create campaign privilege may create campaigns and become campaign authors once the campaign is successfully created.

When a class is added to a campaign all of the class users are assigned campaign roles based on their class roles.

Users with a class role of privileged become campaign supervisors and participants.

Users with a class role of restricted become campaign analysts and participants.

The campaign roles control both data visibility and actions a user may take within the context of a campaign.

To recap, campaigns have four roles: participant, analyst, author, and supervisor.

A campaign has a running state, which is one of running or stopped. Users may not upload survey responses to a stopped campaign.

A campaign has a privacy state, which is one of shared or private. If a campaign is private, analysts may not read the campaign's survey responses.

Campaign Permissions

Operation Participant Author Analyst Supervisor
Create Campaign only users with the campaign creation privilege; the user can only add classes to campaigns that he or she is a member of
Read Campaign Properties (XML, name, description, states) anytime anytime anytime anytime
Read Classes Associated with a Campaign anytime anytime anytime anytime
Read User Roles Associated with a Campaign only show authors anytime only show authors anytime
Update XML (except URN and name) never only if there are no responses never only if there are no responses
Update URN never never never never
Update Name never never never never
Update Running State never anytime never anytime
Update Privacy State never anytime never anytime
Add Class never anytime never anytime
Remove Class never anytime never anytime
Add Supervisor never never never anytime
Remove Supervisor never never never anytime
Add Author never anytime never anytime
Remove Author never anytime never anytime
Add Analyst never anytime never anytime
Remove Analyst never anytime never anytime
Add Participant never anytime never anytime
Remove Participant never anytime never anytime
Delete Campaign never only if there are no responses never anytime
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.