locking classes (read-only mode?)

locking classes (read-only mode?)

by Garret Gengler -
Number of replies: 14

Does anyone know of a quick and easy way to lock a class at the end of a term, so students and instructors in that class can no longer make changes?

For various legal reasons, we are ideally supposed to lock down the instructor's syllabus, assignments, etc., after a class ends... I can't delete the courses, because we want to provide long-term read-only access for students, and we want instructors to be able to reuse the content for future semesters.

I don't see an easy way to do this in Moodle 1.7.x, but I'm wondering if I'm missing something, or if a feature is coming in 1.8/1.9.

If I can't find a better way, I'm thinking I'll have to do some roles trickery.  I'd create some "locked roles" like Student - readonly and Instructor - readonly, and I could write an administrative script to swap out the roles for a given class at the end of the term.

Thanks for your help,
-Garret

Average of ratings: -
In reply to Garret Gengler

Re: locking classes (read-only mode?)

by Steve Hyndman -

Why not just backup the courses (or better yet, then entire site) at the end of each term. The backup archive will contain everything as it was at the end of the term--if there is a legal challenge you have everything as it was at the end of the term regardless of what may have been done afterwards.

Steve

Average of ratings: -
In reply to Garret Gengler

Re: locking classes (read-only mode?)

by Tony Hursh -
Garret, I suspect that our requirements are similar to yours (since we're from the same institution, albeit different academic units).

We do exactly what Steve suggests. We make an end-of-term backup of each course and burn two CDs from each backup. We retain one copy of the CD and provide the second copy to the instructor for his or her own files.

The course on the server is left open for student use -- we don't bother with trying to lock it down in any way. It's actually pretty gratifying to see students returning to their old courses for reference.

We haven't noticed any problem with people changing things after the course is over, actually, but in the event of a dispute we'd consider the CD copy to be the official version of the course as of the end of term.


Average of ratings: -
In reply to Garret Gengler

Re: locking classes (read-only mode?)

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Another option, in the post 1.7 roles and capabilities world, is to override all roles on that course, and remove all the write capabilities. Doing that by hand would involve ticking about a million radio buttons, but it should be quite easy to write a script to automate it. In fact it may just be a single query:

 

INSERT INTO mdl_role_capabilities

        (contextid, roleid, capability, permission, timemodified, modifierid) 

SELECT $coursecontext->id, role.id, cap.name, CAP_PREVENT, $timenow, $USER->id

FROM mdl_role role, mdl_capability

WHERE cap.captype = 'write' AND cap.contextlevel >= 50


Note that this is totally untested. Use at your own risk.
Average of ratings:Useful (1)
In reply to Tim Hunt

Re: locking classes (read-only mode?)

by Garret Gengler -

Hmm.. that's promising... I was wondering if I could do it with a role override. 

My other idea was to define a bunch of parallel, but locked roles like "Student (read-only)" and "Instructor (read-only."), and write a script which would swap out roles for any class you choose.   That approach bothered me because it would require creating a hard-coded mapping table of unlocked to locked role ids.

Burning hardcopy archives (CD/DVD-ROM) is a possibility, but it's not ideal for a couple of reasons:

-- Moodle is just one of a half dozen systems we provide to our students & faculity.  Class resources in all of the other systems (unix web hosting, file storage, wikis, mailing lists, etc.) can be locked at the end of the semester.   So leaving Moodle unlocked but with a permanent copy would be inconsistent.   When you're managing a site with 100 classes a semester, and 4000+ participants, inconsistency means increased user support, which means the phone will ring a lot more when people get confused.

-- A few instructors, if given the rights to edit old classes, invariably will start editing the old semester materials when preparing for a new semester.   We do a fair amount of user training, and do course content imports for instructors, etc... but no matter what we do, there's always someone messin' with their old classes, thinking that's the best approach to create the new class content.

-- On our Moodle site, nightly course backups are taking up an increasing amount of disk space... gigs and gigs.  Every time a change is made to an old class, it's going to trigger a new nightly backup.

Thanks for the advice... I'll figure something out and post my findings...

-Garret

Average of ratings: -
In reply to Garret Gengler

Re: locking classes (read-only mode?)

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
The direct way is (as Tim says) to manually make overrides for every capability in each course which is simple but probably time-consuming.

The best way I can think of would be to create a whole new role called "Read-only user" and set all the write capabilities in it to PROHIBIT.

Then, every time you want to do this you just need to assign everyone to that role in the course (in addition to their other roles). You shouldn't need to swap out old roles. The new permissions of this role will take precedence over whatever they already had.

Average of ratings: -
In reply to Martin Dougiamas

Re: locking classes (read-only mode?)

by K Oda -
I am using Moodle 1.5.2 and cannot upgrade to a newer version.  We have extensively modified Moodle to integrate it and it's management in to a single sign on uPortal.  My issue is that our portal and it's Moodle are served to thousands of high school students.  Keeping the courses "pure" and free of student modification has proven to be a challenge.  As a result, I am in need of an easy solution to lock these courses so that they cannot be edited by any user except the über admin.  I am a php/Moodle newbie so please keep the description of your solutions as simple as possible. THANKS!
Average of ratings: -
In reply to K Oda

Re: locking classes (read-only mode?)

by Josh B -
Hi All,

Has there been any move on the read only course mode?
We are facing the same problem with still allow students access to there old material without the backup problems associated with having so many active courses

At the moment the plan is to create a new student roll each term eg T109 and enroll students into this term in T109 then simply turn off write permissions on this account and enroll T209 students within a new student roll

This will get messy and im wondering if anyone has found a better way to do this

Josh,
Average of ratings: -
In reply to Josh B

Re: locking classes (read-only mode?)

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
As above, you can just turn off most of the permissions for the standard student role - this isn't too hard.

If you want to stop the course being backed up with the active courses then I would recommend setting up a second "archive-only" Moodle where you move the old courses to (backup and restore). This is even easier, because you can change the standard Student role into a read-only role for the whole site.

For authentication the archive Moodle can slave from the active Moodle (either through mnet or simple external database authentication).
Average of ratings:Useful (1)
In reply to Martin Dougiamas

Re: locking classes (read-only mode?)

by Josh B -
Hey,

This is another option we looked into but looks to be very time consuming as we have around 250 courses each term 4 terms a year that would need to be backed up and restored

Josh
Average of ratings: -
In reply to Martin Dougiamas

Re: locking classes (read-only mode?)

by Garret Gengler -

Just a follow-up.

I finally got a chance to implement this for our site...    It seems to be working fine, but it's not an ideal solution.

It requires doubling the role assignments for a given category of courses.  That's a lot of role assignments... and the 1.9.x code for role_assign is very slow.

The basic idea is that I have defined a role called "read-only" which prevents all capabilities that would allow a user to modify course materials.

Then I walk through all courses in a category.   In every course, I get a list of all course participants, and assign each of them the new read-only as a hidden role assignment, in addition to whatever role they already had.

It works a charm, but it is very slow.   Processing a set of 40 classes takes tens of thousands of mysql queries, and 100% cpu, for about 5 minutes.   We can live with that since this only has to happen every few years...  but it would be nice to have a cleaner solution.

It's worth mentioning that I tried to assign the read-only roles at the category level, but that caused problems with the "my courses" block, among other issues.   (Users were suddenly seeing every course in a given semester in their my courses block.)  

My code is just a hack right now.   If anyone is desperate for a solution, please contact me and I'll share what I have.

-Garret

Average of ratings: -
In reply to Garret Gengler

Re: locking classes (read-only mode?)

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers
For what it's worth, we now have this feature in our system too. We implement it as follows:

- Student role has only the 'read' capabilities (we removed all the write ones)
- 'Contributing Student' role has all the write capabilities that we removed from Student [and only those capabilities, not anything else]

Both these assignments are created at the same time, some time before course start. When creating a Student allocation, we create their Student assignment with a 'timeend' set to three years later than the course end date. The 'Contributing Student' has a 'timeend' set to the normal course end date.

The result is that during the 'active' part of a course, students have both roles and can edit things. After that, they are left with just the plain old Student role and cannot.

Setting up the roles is done directly in the database rather than by calling role_assign - a strategy which may not work if you use certain features that we don't, such as forced-subscribe forums... So adding the roles is done with a custom hack, but removing them (after timeend) is left to standard Moodle cron and role_unassign.

This will much more than double our entries in role_assignments - twice as many assignments, plus one of those lasts four times as long before being deleted. We currently have over 700,000 entries in that table and it is going to keep increasing. However, as tables go, that isn't too massive. [Our largest table, an OU-specific one connected to portfolio, has nearly 37 million rows...]

Note that we decided this is probably better than using a 'read-only student' role (with Prevent), which had been our original plan. The role system works best if you only ever use positive (Allow) or zero (Inherit) capabilities, restricting negative ones to specifically negative roles such as prisoners or 'naughty people'.

--sam




Average of ratings: -
In reply to sam marshall

Re: locking classes (read-only mode?)

by Garret Gengler -

Thanks for the details, Sam.  That sounds like a good approach.  I considered adding rows to the db directly, but didn't want to break anything... and we can live with the slow performance of role_assign for the time being.

For speed and simplicity, I do query the database directly (with custom sql) to figure out what users to lock out... but the actual role work is being done by the role_assign and role_unassign functions.

So you don't lock the instructors at all?   In our experience, they're the ones who are most likely to modify old course materials... usually by mistake.    Anyway, our university policy says that course materials have to be locked down after the end of the term, in case a student appeals a grade or sues the university, etc.  That includes preventing instructors from making retroactive changes.

It's also a matter of consistency...  we provide other systems for each course like web hosting space, mysql databases, and Confluence Wiki spaces, that go read-only at the end of the semester.  It is weird if one system (Moodle) behaves differently.

Using prevent at the same context level (course) seems to be working fine for us... but I know the role logic gets very complicated... this is the only place where we are using negative role assignments. 

Cheers,
-Garret

Average of ratings: -
In reply to Garret Gengler

Re: locking classes (read-only mode?)

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers
You're making the assumption that instructors were ever allowed to edit course materials in the first place? Where on earth would you get that idea. smile

Seriously, we have two categories here:

Tutors generally lose access altogether after the course ends - and they don't have access to edit course material anyhow, though while their access lasts, they can of course post to forums and so on.

Course staff keep access permanently, but usually their access does not allow them to edit course material (such as quizzes say) unless they are active in our workflow system (in which case they'll have an additional role); this wouldn't generally be done after the course ends. They could still post to forums and edit wikis and suchlike, I guess we just trust them on that point!

To clarify, I didn't mean to suggest that Prevent won't work - but that life is just a little simpler if you can avoid using it as there is no need to work out what 'wins'. (Petr wants to scrap it in 2.0, though Prohibit will still be there.)

--sam
Average of ratings: -
In reply to sam marshall

Re: locking classes (read-only mode?)

by Garret Gengler -

Ack, I misspoke... In our read-only role, we are using prohibit.. not prevent.  

I can see why Petr wants to scrap Prevent... it's much clearer to just "not set" capabilities which a role should not be granted.

-Garret

Average of ratings: -