Field management

Permission management

cwpermAll administrative accesses to CallWeb are controlled by a set of permissions that are based on modules and projects. Access to questionnaires by respondents and access to CATI interviewer modules are NOT subject to this permission scheme.

If no permissions are defined (such as upon initial use of the system), the site manager must access the cwperm.cgi module in the utility directory and define a super-user (see definition below). This super-user can then define additional users according to site needs.

Key concepts

There are two kinds of users: super-users and regular users. Super-users have access to anything and are the only ones who can use cwperm.cgi to create users and set permissions. Regular users can only perform the tasks that they are allowed according to the permissions set for them by the super-user.

There are six types of permissions, as follows:

  • All modules, all projects: a regular user can be given access to all modules and all projects. This is equivalent to the super-user permissions with the exception that that regular user cannot access cwperm.cgi to create users and set permissions;
  • All modules, one project (or more): a user can be given access to all modules for a specific project (or more than one);
  • All projects, one module (or more): a user can be given access to all projects from a particular module (or more than one);
  • One (or more) projects, one (or more) module: a user can be given piecemeal access to combinations of particular projects and particular modules; this is the finest level of permission control. It can be used, for example, to grant a client access to frequency tables in their project;
  • Generic # Accessible by module permissions: a user can be given access to a selection of modules for projects where they are named in the # Accessible by pound instruction; these permissions have no effect outside such projects.
  • Permissions that are dynamically borrowed from other users: a user can be associated to other users from which it borrows their permissions in real time. These users can themselves borrow permissions from other users (in a cascade).

Users are temporarily locked out of the system if they accumulate three incorrect accesses within a two minute period.

Permission management functions

Once a super-user accesses cwperm.cgi (either directly or via the integrated module), they get a menu similar to the one depicted here. The following functions are available to them:

  • Display the list of users
    This simply lists all user names, for reference.
  • Create a user
    A new user is given a name and a type (super-user or regular user). The user type cannot be changed later on.
  • Change a user's password
    Any user can be given a new password, which needs to be confirmed.
  • Add/modify a user's permissions
    After selecting a user whose permissions are to be modified, a (rather daunting) interface is displayed that allows the super-user to identify which permissions that user shall possess. Each available module is displayed in columns, in addition to a column for all modules. Each project is presented in rows, in addition to a row for all projects and a row for projects identifying the user in # Accessible by. Permissions can be redundant (e.g., a permission for all projects on cwfreq.cgi and a permission on one particular project on the same module). The most liberal interpretation of permissions is made later on.
    A box labelled "Permission level" accepts positive integers; it is not yet in use.
  • Copy permissions from one user to one or more
    Permissions can be copied from one user to one or more other users. A useful strategy using this feature would be to create a fake user that bears the permissions for a group of users and then to copy permissions from this fake user to all users in the group. Permission copying can be dynamic (and change in real time with changes to the permissions of the source users), additive (the permissions of the source user are added to the existing permissions of the destination user without touching existing permissions of the destination user) or can entirely replace the existing permissions of the destination user.
  • Delete a user
    Users can be deleted entirely form the permission system, one at a time.
  • Log out
    This option interrupts the activity of the super-user in cwperm.cgi.

User management strategies

More to come.

Field management

Permission management

cwpermAll administrative accesses to CallWeb are controlled by a set of permissions that are based on modules and projects. Access to questionnaires by respondents and access to CATI interviewer modules are NOT subject to this permission scheme.

If no permissions are defined (such as upon initial use of the system), the site manager must access the cwperm.cgi module in the utility directory and define a super-user (see definition below). This super-user can then define additional users according to site needs.

Key concepts

There are two kinds of users: super-users and regular users. Super-users have access to anything and are the only ones who can use cwperm.cgi to create users and set permissions. Regular users can only perform the tasks that they are allowed according to the permissions set for them by the super-user.

There are six types of permissions, as follows:

  • All modules, all projects: a regular user can be given access to all modules and all projects. This is equivalent to the super-user permissions with the exception that that regular user cannot access cwperm.cgi to create users and set permissions;
  • All modules, one project (or more): a user can be given access to all modules for a specific project (or more than one);
  • All projects, one module (or more): a user can be given access to all projects from a particular module (or more than one);
  • One (or more) projects, one (or more) module: a user can be given piecemeal access to combinations of particular projects and particular modules; this is the finest level of permission control. It can be used, for example, to grant a client access to frequency tables in their project;
  • Generic # Accessible by module permissions: a user can be given access to a selection of modules for projects where they are named in the # Accessible by pound instruction; these permissions have no effect outside such projects.
  • Permissions that are dynamically borrowed from other users: a user can be associated to other users from which it borrows their permissions in real time. These users can themselves borrow permissions from other users (in a cascade).

Users are temporarily locked out of the system if they accumulate three incorrect accesses within a two minute period.

Permission management functions

Once a super-user accesses cwperm.cgi (either directly or via the integrated module), they get a menu similar to the one depicted here. The following functions are available to them:

  • Display the list of users
    This simply lists all user names, for reference.
  • Create a user
    A new user is given a name and a type (super-user or regular user). The user type cannot be changed later on.
  • Change a user's password
    Any user can be given a new password, which needs to be confirmed.
  • Add/modify a user's permissions
    After selecting a user whose permissions are to be modified, a (rather daunting) interface is displayed that allows the super-user to identify which permissions that user shall possess. Each available module is displayed in columns, in addition to a column for all modules. Each project is presented in rows, in addition to a row for all projects and a row for projects identifying the user in # Accessible by. Permissions can be redundant (e.g., a permission for all projects on cwfreq.cgi and a permission on one particular project on the same module). The most liberal interpretation of permissions is made later on.
    A box labelled "Permission level" accepts positive integers; it is not yet in use.
  • Copy permissions from one user to one or more
    Permissions can be copied from one user to one or more other users. A useful strategy using this feature would be to create a fake user that bears the permissions for a group of users and then to copy permissions from this fake user to all users in the group. Permission copying can be dynamic (and change in real time with changes to the permissions of the source users), additive (the permissions of the source user are added to the existing permissions of the destination user without touching existing permissions of the destination user) or can entirely replace the existing permissions of the destination user.
  • Delete a user
    Users can be deleted entirely form the permission system, one at a time.
  • Log out
    This option interrupts the activity of the super-user in cwperm.cgi.

User management strategies

More to come.