-
Notifications
You must be signed in to change notification settings - Fork 25
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
- bit attributes on the user table
- the user's class role
- the user's campaign role
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).
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.
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 |
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.
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 |