General developer forum

This is what I use today
but I think it is ugly at your eyes.

$admins = get_users_by_capability($context, 'moodle/course:doanything');
$admins_id = array();
foreach ($admins as $id => $admin) {
$admins_id[] = $admin->id;
}

$heads = get_users_by_capability($context, 'moodle/course:update');
$heads_id = array();
foreach ($heads as $id => $head) {
$heads_id[] = $head->id;
}

$teachers_id = array_diff($heads_id, $admins_id);

Any better way?
Thanks.

You could use get_role_users if you know which role you want to list.

This is an astonishingly difficult problem. There is no good solution in Moodle 1.x - there is a possibility that there might be one in Moodle 2.

Note that the get_users_by_capability function has a $doanything parameter, I think if you pass this as false, it should exclude admins for you. (You should make sure admins don't have any capabilities other than doanything, in order for this logic to work - that should be the case if they are correctly configured.)

My current preferred solution would be to do the get_users_by_capability then filter the list with a separate query to check whether those users have roles actually on the course context (as opposed to the category or site contexts). This excludes not just admins but also any other super-users. (E.g. we give some people ability to edit all sites within a category, but they aren't 'teachers', neither are they admins.) Note that this may cause performance problems if you have a very large number of teachers or admins (more than a thousand or so on a course) - these problems can be avoided with careful coding, but even we don't have that many tutors on a course, so I doubt other sites do either...

This is not 'correct' behaviour because it might be possible to have somebody assigned at category or site level who really is the teacher for a bunch of courses (that's the difference between your solution that just excludes admins, and mine that excludes anyone without a role on the actual course). I don't believe either solution is right or wrong. Mine works better for our installation/setup of Moodle. But yours might work better in other use cases.

Finally, some parts of the code include lists of roles that should or shouldn't be included in particular displays (as an alternative to the capability approach). I mentioned above that you shouldn't use a single role, but if you provide config option with a list of allowed roles, that can work and is perhaps the most reliable approach in the current situation, however it does involve adding extra configuration for your feature (whatever it is). See the 'gradebookroles' config option for an example of this.


As I mentioned above, there has been discussion about a possible solution for Moodle 2 (where there's a bit of a proliferation of gradebookroles-style options, one of which is mine): some way to indicate that people are actually 'participants' in a course rather than just having capabilities to do things in it. As far as I know this isn't yet resolved or implemented, it was just mentioned at the last developer meeting.


(The situation is even worse for students where course:view is the right capability - then you might have lots of people with roles at site level that let them view all courses - for example we have helpdesk staff in that position.)


Finally - I got a bit theoretical in this mail - but for an actual practical answer to your question, have you tried looking at the code of places where Moodle does display the list of teachers, to see how it does it? Might be best to copy that.

--sam