Increasingly BIM development is getting to the stage where the functionality for BIM’s three different types of user (coordinator, markers and students) are just about complete. I’ve been using a very naive, probably misleading interpretation of Moodle’s capabilities system to distinguish between the different types of users and what they can do. Yesterday, doing what I thought was some minor updates, it broke. I’m currently having to use a kludge to get BIM to work for different users. This post is documents my attempts to fix this problem.
The components of the problem
This task is complicated by the mixture of a number of different domains including:
- CQU practice and the origins of BAM;
Must of the design of BAM is based around CQU practice, where BAM started. The basic assumption of BAM/BIM (at the moment) is that there are three types of user:
- Coordinator – the teacher in charge(s) of a course, can do just about anything.
- Marker – any teacher who isn’t a coordinator. Normally responsible for marking the posts of a subset of students.
- Students – people registering feeds with BIM.
- Moodle default roles;
This is an area of confusion for many and in which I’m still somewhat limited in understanding. My default installation of Moodle has the default user roles of:
- Administrator – can do anything in all courses.
- Course creator – can create courses and teach in them.
- Teacher – can do anything within a course (sounds like a Coordinator)
- Non-editing teacher – can teach in courses and grade students, but not alter activities (sounds like marker)
- How those default roles are being applied at CQU; and
It looks like the CQU installation of Moodle has defined some Moodle roles that are more like the original CQU ones defined above. With BIM I’m in the interesting situation of coming from the CQU context but having to create something that will have minimal CQU assumptions so that other institutions can use it.
- Moodle’s roles, capabilities, permissions and contexts.
Moodle is moving (since 1.7) to a more flexible permissions system. This is what I need to actually use to achieve the melding of the above. This seems to be the best explanation of how permissions are calculated in this regime.
- How you define capabilities etc within an activity block like bim.
What I’m planning to do
With an activity module you are meant to define capabilities that exist for that module in the
db/access.php file. At the moment, I’m hoping to define the following capabilities:
Hopefully, there’s a sensible link between these and the above. In the module code I am using which of these capabilities a user has to drive which part of the code is executed. That had been working. It broke yesterday as I was making changes.
I currently have different user accounts that take on each of the different default Moodle roles. Each of these are configured to receive particular capabilities within BIM. Time to test them and see what bim thinks they are. This is after a re-boot of the computer (separate reason) and so the outcome may be different. I think there was some “caching” issues yesterday.
- Administrator – coordinator (correct)
- Course creator – appears to end up enrolled as a student through moodle. Ignore for now.
- Teacher – coordinator (correct)
- Non-editing teacher – generates an error with no recognised capability
- Student – student (correct)
Okay, seems like non-editing teacher is the only problem. Why?
Dumping out the USER object doesn’t give a lot of information, apart from the fact that this user has a value of -1000 for all the bim capabilities. Which appears to imploy that they don’t have the capability. Yes,
lib/accesslib.php defines CAP_PROHIBIT as -1000. Which implies the capbility I have set to CAP_ALLOW isn’t working.
Is it just this capability. What if I change another? Changing db/access.php doesn’t seem to make any different.
First, let’s find out what role the user has, or at least Moodle thinks he has.
I think it’s working now. Seems that after changing
db/access.php you have to:
- increment the version in version.php
- run the “admin notifications”
- log the use out and then back in again.