About Users, Classes and Campaigns

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