Users, roles
How to manage Users and Roles, access control.
Last updated
How to manage Users and Roles, access control.
Last updated
This whole section is being significantly revamped in OLab4.6
Because we are no longer using the Entrada framework, we also do not have access to Entrada's user management tools. Instead, you should use the tools provided by the parent LMS e.g. moodle.olab.ca
We continue to use Role-based access in OLab4.6, which is much stronger and more flexible than our simplistic approach in OLab3. The internal user interface for role management is not yet developed.
This is for Admin level users only. Do not mess with this if you do not know what you are doing.
We have improved this, taking an approach which is much more standard, and similar to how most LMS applications handle roles, courses, groups etc. Indeed, for most people, role management will be done via an LMS. We are for this but for some groups who do not have access to an LMS, we are developing a System Management Tool in OLab4.
The user credentials, their groups and their roles within the group are set. You have a number of Roles to choose from:
Admin -- the top level administrator. Can edit and control access to all OLab4 objects at all scope levels, including the global-level objects.
Superuser - Can edit and control access to all OLab4 objects at all scope levels, up to server-level.
Director -- Can edit and control access to all OLab4 objects at all scope levels, up to course-level
Author -- Can edit and control access to all OLab4 objects at all scope levels, up to map-level
Learner -- can play and list those maps and courses that are open to their group
Reviewer -- can play and annotate those maps and courses that are open to their group
There are a number of things that are under the control of Roles in OLab4
Scoped Objects - depending on your role, you can edit different scopes of objects
insert xref to that section in Objects
Courses - these are tied to the LMS
Maps - you can control which maps can be played by certain roles.
You can try simply changing the access level in Map Details for a case to Open. This will often work but is not fully debugged.
You, or someone with access to a SQL that is connected to the OLab4 server's database, can also make a small change. You need to create an entry in the security_users table, which points at the correct map_id, is linked to user_id = 1441 (our anonymous user), and with the ACL set to RX. (If that does not make sense, you maybe should not be given access to a connected SQL tool.)
Anonymous access is not quite the same as guest access. Anon needs no login at all and the map will start immediately. With Guest access, the user must still login with the published user credentials of 'guest' for username and password.
More to be added as this is refined. At present, management of these aspects is performed by the System Management Tool. If you wish to explore this further, contact us.
Nodes - you can even prevent certain roles from visiting some nodes. We have .
You can now provide completely open or anonymous access to some OLab4 cases. For basic information on this, check out