|
As for how it's coming along, I am trying very hard (and expect I will succeed, but not quite certain yet) to get it scheduled in this upcoming development period. It was scheduled in this last one, but only at priority 3, and they dropped a bunch of extra tasks on me two weeks from the end so...
About your suggestions: 1) OR - my opinion is that this would complicate the UI. Not that it's necessarily going to result in a bad interface, just that it's harder to implement. I'm firmly of the belief that a first release should have minimal possible features to do something useful - get that working, then develop enhancements in future... (so in other words - I don't want to do it in this release - maybe somebody could add it in moodle 2.1 or so) 2) User and groups - if you are talking about conditions on them ie only show this to users in a particular group, you can already do a lot of this in Moodle 1.9. Look into the groupings feature and the, damn I forget the name, but there's a tickbox that means it's only visible if you belong to a group in that grouping. Similarly if you need per-user things you can probably achieve most requirements using the existing 1.9 role system; if some users aren't allowed to access it then give them a role and override the 'visible' permission or whatever it is, on that activity,. similarly if some users always ARE allowed to access it, you can override to allow them the 'view things even when hidden' or whatever which would let you get into conditional things. So I don't think any work is needed in this area. I should note here there's one suggestion that was made in-house which I'm hoping to use - that is for the grade-specific conditions, to allow you to choose any grade (the initial design document suggests you can only use grades from activities). This allows quite a lot of flexibility because you can create custom grades, import them, write plugins to update grades, etc. So for example another way to prevent certain users accessing an activity under this system would be to create a custom grade and manually (or through some kind of import) give those users a particular grade. Then make a condition on that grade. This should allow for all sorts of other integration especially if you are in a position to write some code (eg if you can do code to set a user grade based on some arbitrary condition, then you can automatically make an activity conditional on it, without needing to go into the condition system code or anything like that). You can even potentially use OR conditions this way if you can create a grade that's updated based on multiple other pieces of information on summative / OR logic - not sure if this is possible without code at present, might not be. I haven't quite worked out if it is feasible performance-wise yet but I hope it should be, we'll see... (yes I am really overdue getting started on this code, I want to do it damnit! hopefully soon now) As conditional activities get implemented, it will be important that the UI remains uncluttered and convenient.
One intelligent default could be the default sequence. To make it even simpler, the completion of an activity should enable the activity just below it and this should be allowed to be configured at the course level. To further aid the teacher, even the completion default should be able to be set from the course settings itself. It would be very useful to provide moduletype-wise defaults for a course. Two that immediately come to mind are: 1. view could be considered completion for resource types Subsequently, while creating /editing the modules, the teacher can fine tune the completion criteria. I checked in db table changes for this, but there is no code yet; I'm starting work on it and hope to have something people can use in a couple weeks.
vikram: I agree there are some possibilities for making a more powerful UI in the manner you suggest. Specific responses: 1) I think the 'sequence' idea and per-module per-course defaults are a bit too complicated a feature. Let's get the basic options in first and when people are actually using them, we will find out what kind of 'speeding-up' features they need. 2) I do think there is room for interface changes on the completion system, for example it would be nice if modules did select an appropriate default if you turn the completion to 'automatic'. [Grade for quiz, view for resource, etc.] However that's to do with the completion system not the availability - I haven't yet made the UI for availability, probably that will be flawed too This code is pretty much done now, patch to follow soon...
PERFORMANCE TESTING RESULTS Course setup:
Test procedure: 1) Clear cookies http://sm449.vledev.open.ac.uk/coremoodle/course/view.php?id=5 and log in. All results show the first page load, then the result if I immediately click 'Reload' in browser (or repeatedly click Reload), ie the result after caching data in session. The first page load varies randomly a bit, I think depending on how long since I last did an access with that user, sorry. Couldn't be bothered to repeat tests etc. There was no difference to behaviour with editing on/off. Patch not installed... [STUDENT] 29/3; 24/0 Patch installed, global switch $CFG->enableavailability off... [STUDENT] 28/3; 23/0 (note this is 1 query faster because I made a performance enhancement that was necessary for some of the other changes to work) Patch installed, global option on... [STUDENT] 31/3; 23/0 Patch installed, 1 completion condition... [STUDENT] 28/3; 23/0 2 completion conditions... [STUDENT] 27/2; 23/0 1 grade condition... [STUDENT] 28/2; 23/0 2 grade conditions... [STUDENT] 28/2; 23/0 2grade and 2 completion... [STUDENT] 28/2; 23/0 I think there should be up to 2 extra queries (1 for grades, 1 for completion info) in the first request, however these are not showing up in the results - probably because the existing completion system was turned on in any case and always retrieves the completion info [dunno about grades though]. Anyhow there doesn't seem to be any particular cause to worry about performance. Here is the patch against current Moodle HEAD. I would like to check this in within the next few days; if nobody has comments by end Tuesday I will commit it after obtaining code review from a developer here.
In addition to the current patch (and obvious changes like the db version number), I am thinking of: (1) Adding to the db upgrade a thing which switches both the 'completion' and 'availability' systems on, for systems with developer debug level. This would be in an attempt to get some testing. (2) Moving the options from the 'experimental' options page to the 'subsystems' options page - imo these should not be hidden in 'experimental' by the time moodle 2 goes live at least, I just put them in experimental b/c there wasn't anywhere suitable at the time. Also of note, I have run out of development time for this feature so it's unlikely there will be significant feature enhancements from me on this unless moodle.com people really insist, however I will of course endeavour to fix any bugs found. Forgot to note one thing - backup/restore of the new data is implemented but not tested because backup/restore doesn't work at all on HEAD right now - once I get this code committed to HEAD I will port it to our 1.9 install and will be able to test/fix backup at that point.
Okay! Wow this took much longer than I thought - however, here are two screencast videos I've made demonstrating the feature. (It would have been one video, but the program I used has a 5-minute limit...)
http://lyceum.open.ac.uk/temp/conditional.html These are intended to be usable now to explain the feature and - if things don't change too much - also possibly as part of user documentation/new-features information for Moodle 2. The URL is temporary however, hopefully they can be hosted somewhere else. Sam, those videos are fantastic and the functionality looks perfect. I'm reviewing the code.
 Hi Sam,
Thanks a lot for the clear easy-to-follow videos helen, if you are offering to put them somewhere appropriate, please do.
I don't really know where is the best place, obviously you are the expert. Thanks Sam, links to the videos are now available here:
Hi Sam,
I am very happy that a real programmer take care of that portion of Moodle and that the 5 years "Meantime" ( see http://moodle.org/mod/forum/discuss.php?d=2948  ) will end soon 
Regrouping and standardizing availability control of all Moodle activities in one place will make Moodle interface more orthogonal and easier to learn. It will require also to remove these redundant functionnalities from modules that actually support them. Maybe a suggestion that was implemented 4 years ago in in Regulate Rights ( see http://moodle.org/mod/forum/discuss.php?d=12511 One of the features of that hack was to make possible in one or 2 keywords ( one or 2 check box for conditionnal activivites ) to allow only few activities at a particuler time and for a particular group and to block all others activities of the site at the same time. Sometime usefull to show only a particular quiz and the related documents without having to hide manually all the other activities. Thanks again, Bernard I'd like to commit this patch tomorrow (my time) - want to get it in before I go away for Christmas, as after this week, I'm away for quite a while.
If nobody gets a chance to review it by then, as noted I will ask somebody here to review it and, after that, commit it - we have a couple days to spot if I broke anything critical before I become harder to contact Jenny reviewed the code with me. This took bloody ages - so thanks Jenny!
I have now checked it into HEAD. This attached patch is the one that was committed. I'm about to resolve this bug as fixed. Trivia fans may be interested to know that I will hopefully also post a 1.9 patch here when I've done it. However that patch will be for OU Moodle 1.9 and will very definitely not apply to standard Moodle, plus if you did manage to apply it you'd be up the proverbial creek without a paddle when it came time to upgrade to the real 2.0... but just in case anyone wants it, I'll put it here. Thanks, Sam!
We were still looking at it here, but hadn't come across any problems with the approach yet (just tiny things like whitespace which we can easily fix in HEAD now) Have a great Christmas! Hi Sam,
I was wondering if OU was using this feature in 1.9 already and if you had a patch available. The idea is to implement a conditional activity patch instead of activity locking patch. I looked at the attached patches to this ticket, but they look like their for Moodle 2.0. Cheers and thanks, Mark: I have attached the conditional activities patch against OU Moodle 1.9. I think the patch is reasonably correct etc but there were probably some bugfixes since the patch.
Also note this code has not been tested in the wild yet - it is in our tree, but won't be live to students for another couple of months. Unfortunately there are very many changes in this area in OU Moodle (for example we already had the date feature, but implemented differently). So the patch is very unlikely to apply at all to any other Moodle and some parts are irrelevant. It might be possible to apply it manually - but it'll be tricky, and I can't offer any help. If you want to have a go... good luck [And of course if you do manage to make a patch that actually applies to standard Moodle 1.9 - or even to something closer to standard than OU Moodle - please attach it to this bug...] Thanks Sam! I'll have a look at this during the month and see if we can implement it or not. Cheers!
Hi Sam, I started to look at the patch and it includes patches against lib/completionlib.php which doesn't exist in 1.9. I'm wondering if the wrong revisions or something were chosen for creating the patch? If no, then could you please attach your 1.9 lib/completionlib.php?
Yeah, the more I look at the patch, the more is missing, like backuplib.php patches are patched against a version of backuplib.php that already has some of the conditional fields being backed up. Let me know if you can provide an updated patch or not (if no, I might be able to backport from Moodle 2.0 - though that might be really painful hah).
OK, I think I'm discovering some of my own confusion, this patch is supposed to be applied after the completion patch (
Mark: Yes sorry I forgot about that
You might be able to remove the completion-related parts of this patch (so that it only does grade and dates) while porting it. Of course, that probably wouldn't be easy, so giving up the idea might be the only option. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sub-task
Resolved
Minor
 |
|
I wondered how this was coming along?
Would it be worth considering adding Boolean ORs in addition to ANDs and to include conditions based on user and group?
Cheers,
James