Moodle

Our site would benefit greatly from this proposed change. It makes sense in my mind to separate :view and :participate, because our teaching staff need view rights to all other timetabled courses without all courses being listed in the My Courses block. I'd be very keen to see this implemented in 2.0.

To think about ...

I have also run into this problem. I did an almost identical fix (called the capability course:enrolled but it does the same thing). I also found that a line needs to be changed:

$canviewroles = get_roles_with_capability('moodle/course:view', CAP_ALLOW, $context);
needs to change to:
$canviewroles = get_roles_with_capability('moodle/course:enrolled', CAP_ALLOW, $context);
in user/index.php

The related forum post is here: http://moodle.org/mod/forum/discuss.php?d=107390

Mike

There have been a bunch of posts in the roles forum about this very issue as of late, and it would be a good fix for one of the things I'm trying to do and several other people seem to be attempting something similar... -

I'm coming from a "helpdesk" perspective - where I want the ability to give roles to certain users to get into courses (without being listed as a participant AND without having full admin capability AND without listing every course on the frontpage or My Courses block AND while blocking other functions such as view grades, etc. ) - I've nearly got that, except that the user is still listed as a participant in every course.

I hhave found another place where this needs changing- mod/forum/lib.php line 350

This would also help solve these issues
http://moodle.org/mod/forum/discuss.php?d=107267
http://moodle.org/mod/forum/discuss.php?d=106274

There's a clear need for an invisible entity who is omniscient but who can be empowered to do nothing or only certain things.

I agree with this fix completely. From a help desk perspective, each help desk technician needs the ability to "see" the classes in order to help students. But they are definately NOT participants. I don't give help desk technicians full admin access for obvious reasons. I manage almost 20 Moodle sites and this causes a lot of consternation.

It would be a great help to our faculty if teachers were able to view all course pages without needing an enrollment key and without actually enrolling in the course. Mentors could check course work for their mentees and teachers could learn from seeing how other teachers use their MOODLE pages. However, their MY COURSES block on their home page should only list courses that they are actually responsible for editting. Teachers who are viewing another teacher's page should not be able to view grades.

[In reply to Edwinna Lucyk]

This is exactly what this bug is about. If you are willing to modify the core code then making the changes above and giving the course:view capability in system context will do what you want

I would strongly discourage anybody from modifying 1.9x - this problem is far more complex than it seems, I am trying to find some better solution for 2.0 right now

Here is a patch that details the changes I've made (this is to document what I have done as much as anything else)

Sorry, last one was missing the local/db/access.php that is needed to create the capability. Version.php will need incrementing but I'm not sure the best way to do this.

Also I'm not sure if the lang string belongs in local/lang or in lang, also should the capability be named something like moodle/local:courseenrolled

Yes, I think it is worth doing. Since I voted for this in November, I've seen a lot more need for a role somewhere between God and teacher.

I have also voted and have similar issues.
I would like to create a role that allows the user to view all courses, not show as a participant, but not be able to edit the course i.e no Editing button available.

Being able to choose whether or not they can be seen in courses in a role setting would be great.
And excuse me if its already in v2.0 but I agree with Ben Reynolds when he commented about a role between god and teacher.
Perhaps breaking the "allowed to do anything" setting into subsets e.g
Allowed to view all courses
Allowed to Edit all courses
Allowed to remain hidden

Allowed to do anything might aswell just be called "admin".

I think Mike is on the right track. I need a flag that tells whether someone is enrolled in a class, and course:view isn't it. Roles seems an odd place to put this, but that's the design as it stands. I'm just wondering if one additional flag is going to be enough to cover all of the situations. I'm seriously considering implementing Mike's patch as we are not going to be able to migrate to 2.0 before next January. Is it working well for you, Mike?

I've been using this change for about 7 months now, apart from the forum mail issue it is going well. Although bear in mind that our teachers are not the most adventurous bunch with the different modules available so it is possible (if not likely) that there are issues with some modules that aren't used here.

We too have a need for a role between admin and teacher and despite Moodle's incredible degree of flexibility in building roles with granular permissions, we could not find a way to meet the needs of our support center staff without custom development. We created a support-enroll tool. Users who have access to this role enroll themselves in any course temporarily. During that time they are visible, temporary course participants.

Our full time support professionals are allowed to enter courses from any computer location. Our student support staff are allowed only from wired computers located in the support center (their personal laptops or dorm computers don't allow access to the support-enroll tool). Everyone is expected to unenroll from supported courses each day at the end of their shift, but just in case, they are bumped out of all courses that they support-enrolled in at midnight each day.

For both roles, they are blocked from entering as support staff if they already have a role in the course. Thus, our support students do not enter courses that they are enrolled in via the registrar's office.They no longer have every course at the university listed on their MyMoodle gateway page, allowing them to be part-time students or instructors as well as part-time support staff.

I wonder if there was a way to have users enroll and unenroll without a custom development solution. If not, we'd be glad to share the code.

In order to get my patch to actually create the capability you will need to create local/version.php:

?<php
$local_version=2009052600;
?>

(the version number can be anything higher than what is already there)

and local/db/upgrade.php:

<?php
//local capabilities don't get created without this
function xmldb_local_upgrade(){return true;}

I've found another place where it needs changing if patching 1.9: user/index.php line 65

I was about to post this as a new tracker item, but then I found this one!

I have several custom roles that are assigned at the system or category levels and can view all course pages, e.g. User Support staff, Library staff, Disability Services staff. Because these users all have moodle/course:view set at the system level, they appear in many inappropriate places within Moodle courses, for instance:

The Participants list.

The list of potential group members when adding members to groups.

The "Locally assigned roles" tab in every activity.

Recent Activity Block > Full Report of Recent Activity > Show Advanced: User drop-down box

In Choice results, when the "not answered" column is displayed, Admin users see system-level users (but, fortunately, Teachers do not)

It would be ideal if Moodle had a built-in capability for designating various roles "course member" roles. Roles without this capability could be ignored when generating lists of users for, e.g., course membership or potential group membership.

This is fixed in HEAD for 2.0.