User Permissions

From Dokeos

Introduction

Currently dokeos has only a basic permission system. You are either platform administrator, course administrator or student. The platform administrator can do everything and has the most options. He can can configure the platform to his likings. The course administrator can create and manage courses. He can do everything within the constraints of his course: add items, edit items, move items, delete items, ... The lowest level of permissions can do only a limited number of actions: post a forum message, post a student publications, look at other items.

It is not uncommen that you have a student who should be able to do more than just reading the material that you put online. Maybe you want to give him certain rights on certain tools. All this is possible with only minor changes.

The idea

The idea is that you can give the permissions to a student for each action (mostly add, edit, delete, change visibility, move) inside a tool. Each functionality of a course that a course admin can perform is uniquely identified by the tool and the action itself. some examples: ADDING a LINK, DELETING a DOCUMENT. We can conclude that we have a grid of permissions with on the one axis the tools and on the other axis the actions (mostly add, edit, delete, change visibility, move).

This view is maybe a little naive because of two reasons:

• sometimes one tool (a tool considered to be the modules and defined as constants in main_api.inc.php) can have more than one add action, more than one edit action. The best example here is to look at the link tool. You can add a link but you can also add a link category. The the X axis will thus become larger than the number of tools.
• the grid is not perfect: not every action is possible inside a tool. In the links tool you can hide a link (from dokeos 1.6 on) but you cannot hide a group category (yet).

The code has to take this into account (and luckily it does).

screenshots

Giving a student permission to edit links in the links tool

the student test test can now edit links although he does not have the course administrator privileges

code

The code changes are really minor.

• a small permissions.inc.php page that is included in userinfo.php (permissions are with this code only set on the user level and not yet on the group level)
• small changes on api_is_allowed_to_edit to take these permissions into account
• each tool has to change the api_is_allowed_to_edit call by adding the tool constant (defined in main_api.inc.php) and also the action it want to check check the permission for. Sometimes only one api_is_allowed_to_edit call is used for a whole block of code (for all the actions that only the course admin can do). With this permission scheme this can no longer be the case. You have to repeat the call for each action (and change the second parameter in the api_is_allowed_to_edit call)

permissions.inc.php

The code is too long (although only 80 lines) to display here. You can download the zip package and look at the code. The code has the neccessary lines of comment.

A little bit of code explanation:

• When the permissions are submitted we have to remove all the previous settings of that user. This is inherent of the behaviour of the checkbox as the not-checked checkboxes do not occur in the $_POST variable. It can be solved by comparing the existing values to the submitted values but deleting them all before storing only the new ones is probably easier (and maybe even faster)

• The array $possiblepermissions stores all the possible permissions throughout the tools. In casu this is add, edit, delete, visibility, move. Other actions might occur.

• The $allpermissions array is an associative array with the tools as key. This one stores which actions are possible for a given tool (the key). In the links for instance you can hide links but not link categories (yet). By consequence this results in the following code

// the possible actions for link categories
$allpermissions[TOOL_LINK]=array("add","edit","delete","visibility", "move");
// the possible actions for link categories
$allpermissions[TOOL_LINK."_category"]=array("add","edit","delete","move");

This method prevents the displaying of a checkbox for a given tool where it is not relevant. In the first screenshot for instance you see that there is no checkbox in the visibility column.