Moodle

I agree 100% with this. I have an issue with teachers trying to rename courses especially the short name. It would be great if we could prevent them from making this change

We are frequently encountering teachers changing the name of courses for which we are trying to adhere to a specific course name syntax. I believe that the institution should have the ability to decide whether or not course names remain unchanged or can be changed by teachers.

I would add the Course ID Number to the list of things teachers shouldn't change. If a class is linked to another system via the course ID number and the teacher changes that number, well, we can all see where that would lead!

I'll add that I've been modifying our code to limit the capability to change shortname and idnumber to those with moodle/course:create at the category context. I would be nice to see an option for this somewhere in the administration block - who is able to change this information? - or add three more capabilities - moodle/course:changefullname, moodle/course:changeshortname, and moodle/course:changeidnumber, defaulting to allowing this for editing teachers, but giving us a way to disable this for our teachers.

We just started using Moodle and we ran into this issue as well, ours is more along the lines of we are only worried about Course ID's, but would love to be able to have teachers change all but Name, short name and Course ID, they should be able to add or subtract more topics, or weeks in the settings functions, also we think taking this way is also taking away some editing functions, like moving around resources.

This seems like a good request. I like Matt's idea of using course creator as the check. We do something similar in allowing admins to limit which user profile fields are editable by the user, I see no reason we could not set it up so that the admin could determine which fields are editable by course creator only. I'll add this to my list of issues to play with if I have time and see if I can come up with a patch but in all likelihood Eloy will beat me to it as I'm buried with classes, books, reading, etc. and do not have the time I would like to play with these types of issues. Peace - Anthony

Implemented Matt's solution to 1.9 and merged into HEAD.

How has this been implemented? Matt suggests two methods in his comment.

Ray - I am checking this out now and hope to create some documentation for it. Peace - Anthony

Ray - It is pretty simple. Nicolas created three capabilities

moodle/course:changefullname
moodle/course:changeshortname
moodle/course:changeidnumber

To disallow teachers to change one of those, go to Users->Permissions->Define roles and edit the teacher role. By default, the teacher has these capabilities so they simply need to be set to prevent to prevent the teacher from being able to edit those fields.

Peace - Anthony

Great. Thanks for checking this out.

Yet another useful configuration option!

I added the documentation at http://docs.moodle.org/en/Add/edit_courses#Adding_a_course

Also added:

http://docs.moodle.org/en/Capabilities/moodle/course:changefullname
http://docs.moodle.org/en/Capabilities/moodle/course:changeshortname
http://docs.moodle.org/en/Capabilities/moodle/course:changeidnumber

and edited:

http://docs.moodle.org/en/Course_settings to alert teachers if they suddenly find they cannot edit that the site admin has removed the capability.

reopening, please add proper risk description to new capabilities

I do not understand the changes in course edit_form.php, those fields are required and if user does not have these caps he/she can not add course at all

in anycase the will cause serious regressions in custom roles because these will not have these defined!
we would have to base it on both moodle/course:update during upgrade

this is extremely urgent

proposal:
1/ base value of new caps on moodle/course:update ASAP
2/ ignore these tests when adding new course - put the code into definition_after data instead

should be fixed now, please review and retest, thanks

Petr - Thanks for the good catches on this. I learned about hardfreeze and clonepermissionsfrom. I am in the process of testing now. Peace - Anthony

Thanks Petr, good catch

This is awesome! Thanks everyone!

One question: will this be rolled out in a patch to the current 1.9.x version or in the 2.0 version?

Thanks!

Mary - If your site administrator downloads the latest stable or weekly version of 1.9 (or 2.0) then you see this feature included. It has been checked in to the 1.9 STABLE and HEAD branches. Let me know if that is clear. Peace - Anthony

Are you sure it's been added to STABLE? And if so, should new features be being added to the stable/weekly release?

From the d/l page for 1.9.2 + MOODLE_19_WEEKLY

"BEST CHOICE FOR A NEW SERVER! The 1.9 stable branch is continually being improved with new bug fixes since the last release (but not new features)."

Ray - Looking at http://cvs.moodle.org/moodle/course/edit_form.php?view=log&pathrev=MOODLE_19_STABLE shows that it was added to 19STABLE. The tracker issue is listed (which could be debated) as an improvement to the existing functionality. I think whether it is a new function or improvement is up for grabs but your point about not introducing new features into 19STABLE is a good one and something to keep an eye on. Peace - Anthony
p.s. Based on the popularity of the issue, I think it is probably a good thing in this case that this improvement was was made to 1.9.

Anthony - You deleted the following comment from your reply "p.s. Based on the popularity of the issue, I think it is probably a good thing in this case that this improvement was was made to 1.9."

Just to comment on this in general. Adding new features to stable releases causes havoc to a greater or lesser degree when the expectation is that a, say, weekly update only includes bug fixes. It's the sort of behaviour that detractors of OS point to as making it unsuitable for enterprise/serious. This probably true for both new feature and improvements.

Also most users don't keep as close an eye on these things as we do, adding to perceptions of lack of stability.

Hi - Will the course name, short name and ID still display (but not be editable) on the course setting page for teachers where the permissions have been set not to allow them to modify these fields? I saw this running on a test server we have, and the name fields didn't display on the course setting page for teachers. I think it would be useful for this info to display here. Thanks.... Brian

Ray - Ooops, I intended to add the p.s. not delete it but at least you saw it. I think your reminder to not add features/even improvements generally speaking is a good one and worth reminding developers. I agree with the theory but also recognize that there are times when it may better serve the community to make a conscience (but deliberate) choice to add something to a released version. My sense has been that we generally run new features by MD and the question about impact has ranked highly when making that choice. Peace - Anthony

Brian - I'm pretty sure that the patch (at least what I saw committed) allows for those fields to be visible and show (just not editable). As I understood the code that is what the hardFreeze function was to do. Although I've not actually tested to see if it in fact works. I just looked at the patch:

if ($course and !has_capability('moodle/course:changefullname', $coursecontext)) {
$mform->hardFreeze('fullname');

Peace - Anthony

Ray is correct about the general policy, however we do occasionally add features/improvements to STABLE when:

1) the feature defaults to previous behaviour (ie it's something you can switch off/on), or
2) the feature re-implements something that was removed in a previous release, or
3) the feature is small and there is a huge number of votes for it and the next major release is a long way off

(In this case it's 1 and 3)

Tested on 1.9 and 2.0, it works fine. Thanks everyone for your work and comments on this issue.

I am really glad to see this added to core. We just did a custom course settings block for a client, to provide this but with a couple of extra capabilities

Our project included
Category
Full Name
Short Name
Course ID #
Summary

The course description and category are equally important to control for many organizations. This is especially the case for schools using an enrollment integration.

I can have Akin Delemare who did our work on this create a patch file to add two more capabilities if they would be accepted into core.

Sure Jonathan, that'd be great! We've come this far!

I'll let Akin know and we'll post something shortly.

The zip contains 3 patch files created using diff.

role.php (lang/en_utf8)
edit_form.php (course)
access.php (lib/db)

2 more capabilities have been added with a context of COURSE:
moodle/course:changesummary
moodle/course:changecategory

Note:
If the user has the moodle/course:create capability but does not have the moodle/course:changecategory capability, the user still cannot edit the course category.

So suggest moodle/course:changecategory capability Allow for Course Creator and Admin and Not Set for all others?

Akin, thanks for your patch.

Reopening to set a new fix version.

Thanks for everyone's comments and votes.

Nicolas, any progress to report on fixing this issue for 1.9.6?

Nicolas, can you get this into 1.9.6 please?

Implemented in 1.9 and 2.0, thanks for the feedback and the patch.

Nicolas, thanks for finishing fixing this issue.

Documentation about the new capabilities now available:

http://docs.moodle.org/en/Capabilities/moodle/course:changecategory
http://docs.moodle.org/en/Capabilities/moodle/course:changesummary
http://docs.moodle.org/en/Course_settings
http://docs.moodle.org/en/Add/edit_courses
http://docs.moodle.org/en/Moodle_1.9.6_release_notes

I'm having a problem understanding the course:changecategory capability. On a 1.9.6 test server, I set this to Allow for the Teacher role. Yet on the Course Settings page, the Teacher does not have the ability to change the category. There isn't even an option for this. Am I missing something fundamental about this?