Issue Details (XML | Word | Printable)

Key: MDL-7796
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vy-Shane Sin Fat
Reporter: Matt Gibson
Votes: 8
Watchers: 12
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

Default permissions for Course Creators are too permissive

Created: 05/Dec/06 01:05 AM   Updated: 31/Dec/07 08:57 PM
Return to search
Component/s: Authentication, Roles
Affects Version/s: 1.7
Fix Version/s: 1.7.2, 1.8, 1.9

Environment: Apache, Win2k3, Active directory

Database: Any
Participants: Alick Brown, Martin Dougiamas, Matt Gibson, Nicolas Martignoni, Rich T and Vy-Shane Sin Fat
Security Level: None
QA Assignee: Nicolas Martignoni
Resolved date: 16/Feb/07
Affected Branches: MOODLE_17_STABLE
Fixed Branches: MOODLE_17_STABLE, MOODLE_18_STABLE, MOODLE_19_STABLE


 Description  « Hide
The LDAP course creator function no longer functions in a usable way compared to 1.6.3. Course creators now have administrator rights to other people's courses and are not constrained to just the ones they have created. There needs to be a way to re-create the old function using the new roles so that it is possible for a course creator not to have editing rights everywhere. Even being able to edit just within a category is not satisfactory as people can still interfere with each other's work.

I suggest some sort of primary course user feature like there is currently a primary site admin who cannot be removed. The primary course user would be the person who created the course and would be permanently assigned as admin at course level. That way, moodle/course:create can be the only capability a course creator has at site level, but when they create a course, they will have total control and can always be hidden using the upcoming hide assignments in 1.8.


 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Matt Gibson added a comment - 11/Dec/06 08:48 PM
This is also creating the problem that the news forums where everyone is subscribed are sending out messages to all teachers. Moodle has become the most effective spam engine the school has yet encountered.

Martin Dougiamas added a comment - 11/Dec/06 11:56 PM
Just change your definition of a "course creator" ... you have that control now by editing roles.

Admin >> User >> Permissions >> Define roles

You probably want to remove moodle/course:view from the role, and maybe others.


Matt Gibson added a comment - 12/Dec/06 07:10 PM
Thanks Martin - I've stripped down the course creator role to nothing but moodle/course:create and it's fixed the access and editing issue. I have set it so that normal teachers can update course settings, so now the only issue is that creators cannot delete courses they have made. Could we have a 'delete own courses' capability to fix this?

The problem still remains that my course participants list still has loads of people in it who don't want to be there. I think Yu said that this can be fixed using the hidden assignments thing in 1.8, but will this still leave the problem of bulk messaging from the news forum when it's set to 'everyone is subscribed'?


Matt Gibson added a comment - 12/Dec/06 07:13 PM
Maybe if the moodle/course:create capability didn't cascade down past the course catagory level like all the others do, then this would not happen. It wouldn't matter too much as it has no functionality beyond that level anyway. What do you think?

Martin Dougiamas added a comment - 15/Feb/07 09:38 AM
The quick fix is to alter the course creator role (Admin > Users > Permissions > Define Roles and remove all the permissions relating to course editing (change them from ALLOW to INHERIT).

Especially these:

moodle/course:manageactivities
moodle/course:view

but many others too.

The reason is that if you assign this role as it is to someone at SYSTEM level then they will have these permissions for ALL contexts below it (ie all courses).

The fact that the default permissions are set like this is a mistake that we need to fix in Moodle. Vy, can you revisit lib/db/accesslib.php in 1.7 and 1.8 and fix the default permissions?


Martin Dougiamas added a comment - 15/Feb/07 09:40 AM
(Sorry Matt, I just realised I'd commented on this before and missed the subsequent comments, I was cruising in "version control" mode)

I'm not sure of the best way to allow deletion only of one's own courses, we'll look that that.


Vy-Shane Sin Fat added a comment - 16/Feb/07 04:52 PM
I've checked in fixes for 1.7, 1.8 and HEAD branches.

Changed most course creator permissions from allow to inherit, made changes to course deletion to allow course creators to delete the courses in which they can manage activities.


Alick Brown added a comment - 16/Feb/07 05:30 PM
Where can I get this fix for 1.7 please?
Thanks
Alick

Vy-Shane Sin Fat added a comment - 19/Feb/07 05:59 AM
Hi Alick,

You can get the fixes from the latest code in the 1.7 or 1.8 stable branches from CVS. Unless you are doing a brand new installation of Moodle, you should also change most of the Course Creator permissions from "allow" to "inherit". Except of course for moodle/course:create and a few others as you see fit.


Rich T added a comment - 01/Mar/07 10:38 AM
Hi,

I have all permissions for "Course Creators" set to "Inherit." Except for moodle/course:create and moodle/course:delete. (Set to 'Allow')
ALL course creators are still showing in ALL courses as participants.
This is causing such things as teachers not associated with courses receiving emails from the other courses. They have nothing to do with these other courses yet they are receiving the emails (assignment submissions, etc).
I can't tell you the number of complaints that I am receiving every day on this. (Sorry-just a quick vent)
Is my only choice to go with 1.8 to resolve this issue?
We, too, use LDAP authentication with certain contexts designated as "Course Creators."
Using the latest 1.7 stable release.

As always, thank you for your fine efforts!

Rich T


Nicolas Martignoni added a comment - 31/Dec/07 08:57 PM
Closing, as this is fixed.