Moodle in English: Conditional availability: Enhancements including OR conditions, plugins

Skip to main content

Future major features

Conditional availability: Enhancements including OR conditions, plugins

This discussion has been locked because a year has elapsed since the last post. Please start a new discussion topic.

Hi all,

At a recent Moodle developer meeting, I introduced a proposal to significantly improve the conditional availability system.

(my part starts at about 01:00 and runs until about 07:00)

Some key parts of this improvement are:

Allow OR (and NOT) conditions.
Improve the user interface for availability restrictions on the activity/section settings form.
Make restriction types (date, grade, etc.) into plugins.

I've now filed a Moodle Tracker issue MDL-44070. Attached to that issue is a Word document with a fairly detailed outline of the development. If you want a quick overview, I'd suggest the presentation above - if you have questions about the detail, please go to the tracker issue and look at my document first.

As a member of the Moodle community, here are some ways you might want to contribute now:

If you like the proposals and want to see them in Moodle 2.7 (or whatever version), please vote for the tracker issue.
If there is something important I've forgotten or that won't work, or you have other concerns about the change, or you think restricting access to anything is a waste of time because the NSA can read it all so why not students, go ahead and say so.
If you have a feature/improvement you'd like to be included in this change which isn't yet, feel free to ask (let me know the MDL number for the feature request). I'll try to avoid increasing the scope - it's already a rather large and monolithic change - but even if I don't want to include it, I can at least consider how well your improvement would fit with this change.

Important caveat: this relies on my time being allocated to the development by my employer (The Open University). I don't yet have full confirmation of this but it is looking positive so I am ready to go ahead with investigation, prototyping, etc. So just a warning that I might have to stop or delay development later if something else comes up, but I hope that doesn't happen.

That said, I think this is going to be a really nice improvement because the current interface is pretty clunky and limited, so I'm hopeful that most people will like it.

Thanks for reading.

--sam

Average of ratings: Useful (8)

Permalink | Reply

I voted - I think this could be a really useful; the and/or/not bit has been asked for on many occasions here and could be great

Average of ratings: -

Permalink | Show parent | Reply

Sam,

Your proposal looks great, I have teachers who would be thrilled to have that functionality.

I do have one question about something in your proposal,Will it be possible to create restrictions by just using groups or will it require groupings? (For example if I have an assignment activity that I only want members of Group A to access, would I be able to restrict it to that group directly in the interface or would I have to create a grouping that contained only group A and then restrict it to that specific grouping?)

There was an older feature request for this... MDL-30554.

Thanks,

-Steve

Average of ratings: -

Permalink | Show parent | Reply

Good question!

The answer is, no these changes currently planned will not make it possible to create restrictions by just using groups.

BUT that's a very obvious extension to do immediately after these changes using the newly-created plugin system. (I'm not committing to doing it, but I might well - I'll make a note.) I.e. there will be a grouping plugin as part of the main change, afterwards we could just add a group one with relatively little work.

Looking at that issue MDL-30554, basically I objected to it because it duplicated a whole stack of functionality, increasing the maintenance cost and complexity etc. With this new proposed system, because it will have a proper plugin API, there will be no need to duplicate anything.

Thanks

--sam

Average of ratings: -

Permalink | Show parent | Reply

Hello Sam,

just added my +1. In my opinion a very good improvement.

Average of ratings: -

Permalink | Show parent | Reply

have put vote in tracker for this triaged feature

Dawn

Average of ratings: -

Permalink | Show parent | Reply

I mentioned that as part of this change it will be necessary to slightly change the wording used for displaying conditions (these appear to students when they don't meet the conditions, and also to editing staff).

This turned out to be super complicated, but with a little help from Tim Hunt, I now have a plausible approach for the new wording (this is linked with the new API). I'm posting it here just in case anybody wants to comment. I'm not actually planning to substantially change the way this information is displayed - it might be nice to do so (e.g. make it fold up with a JavaScript reveal link if it's long) but that can be done as a future change if required. This is really about wording.

At present, the wording for students is done like this; each condition has a piece of text. If there is a single condition, we display only that piece of text. If there are multiple conditions, we display all the pieces of text in a bulleted list. That's it.

Because of the wording involved, this doesn't handle the case of OR conditions, so I need to change it. The new proposed approach is.

Each condition has a piece of text. This now describes only the condition itself and does not contain the words 'available if.../unless...'.
We display standard text 'Not available unless:' before the condition or before the list of conditions. If it's an OR condition, we show 'Not available unless any of:' instead.
A common use case is for an activity to have only a single date condition. The API will allow for conditions to output different text if they are the only condition that applies (which I'll implement for date conditions), bypassing the 'Not available unless:' text.

Worth bearing in mind that, as at present, you can still choose to hide the activity entirely instead of showing it to students with the list of restrictions, if that's more appropriate for your situation. You might choose to do this if the restrictions are very complex, as in my fourth example.

Below I've included some examples. If anyone wants to suggest improvements to wording (particularly around the 'all of / any of', etc.), please do.

--sam

Example 1: Single date condition

1a.

Available from 5 December 2014.

1b.

Available until end of 7 December 2014.

Example 2: Single other condition

2a (completion).

Not available unless: Participation statement is marked complete

2b (user field).

Not available unless: Your Department is equal to Maths

2c (grouping).

Not available unless: You belong to a group in Tutor groups

Example 3: Multiple conditions

Not available unless:

It is on or after 5 December 2014
It is before end of 7 December 2014
Participation statement is marked complete
You achieve a required score in Block 4 self-assessment

Example 4: Multiple conditions (OR and nesting)

(This example is pretty complicated and I hope would be rare in reality.)

Not available unless any of:

All of:
- It is on or after 5 December 2014
- It is before end of 7 December 2014
- Any of:
  - Participation statement is marked complete
  - You achieve a required score in Plagiarism practice
You belong to a group in Teacher's pets

Average of ratings: Useful (2)

Permalink | Show parent | Reply

Sam-to confirm, you are happy with 'not available unless' yes-? Am thinking tis a long established tag?

Otherwise, just a wee thought.... how about something like the following across the board:

Restricted Availability Unless ( then last awkward one could have in addition something like-(can play with it abit): R A U One or/more/ all of the following):

- item

-item

-item

gets rid of all of/any of

and standardises across it all....perhaps......or could stick with not available unless and last awkward one could just be N A U one and/or all of the following.....

cheers,

Dawn

Average of ratings: -

Permalink | Show parent | Reply

Hmm..I don't get the 4th one (though as you say it would be rare)

Are you saying for it to be available you have to EITHER be in the Teacher's pets group OR it is between 5th and 7th December and you have either completed your participation statement or you got a certain score in the Plagiarism practice?

If that's the case then I do get it

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Cor blimey Mary,

thanks for the nudge I honestly missed that gag. Need to be on full alert with the Devs here eh!

cheers,

Dawn

Average of ratings: -

Permalink | Show parent | Reply

Mary: Yes you do get it! Congratulations.

The example may have been a bit silly.

--sam

Average of ratings: -

Permalink | Show parent | Reply

I'm happy-ish with 'Not available unless'. That's wording taken from the current system, the main difference is that instead of including that wording with each individual condition (current system is like 'Not available unless you achieve a certain score in Fun Quiz'), the 'Not available unless' part becomes separate, either before a colon if there's only one condition, or as a heading to a list if there are several conditions.

Don't like 'Restricted availability unless', sorry, I think that wording is even scarier for students. I like things that are (a) simple and (b) short. (Obviously both of those fall out of the window with the last example whatever the wording is, but you know, it could be even worse.)

Basically what I've proposed is the best that I (and Tim) could come up with, and it is also similar to the current wording, so I'm reasonably happy with it. Just posting here in case anyone else has a genius idea. I've already had to redesign my entire API so I can do this kind of output, so I'm hopeful that any other genius ideas won't be so genius that they require me to redesign it again.

The string I'm most doubtful about is 'Not available unless any of:', which I don't think is strictly speaking correct, but 'Not available unless any of the following are true' is really long and sounds totally like a programmer's way of describing something rather than something we should be telling students. Another option is 'Not available unless one of:' but really that has the same problem.

If other people are like 'eh whatever that looks okay' then there's no problem, we'll go with it.

--sam

Average of ratings: Useful (1)

Permalink | Show parent | Reply

I think I'd put myself in the If other people are like 'eh whatever that looks okay' category I share your doubtful thoughts about "Not available unless any of..." but I certainly haven't had any more genius idea. There is "Not available unless one or more of" I suppose, but that's no shorter.

Average of ratings: Useful (1)

Permalink | Show parent | Reply

mmmm......just got this. Understand your logic.

Can only narrow it down to four words (succinct though)....might be clumsy-not sure....but feet in student shoes here:

'unavailable unless following conditions'

bit tricky...Sam-don't envy you (and Tim)!

Dawn

Average of ratings: -

Permalink | Show parent | Reply

Hi Sam,

Thankyou for working on this - I am sure teachers will appreciate additional options for activity availability and use it in creative ways.

I need to post here the design flaw with this proposal that needs to be resolved before this goes ahead.

Currently there are 2 kinds of conditions that can prevent a user from seeing an activity:
1 - A permanent sort of condition like enrolment status, or group members only
2 - A transient sort of condition like completion - even though the student can't see the thing right now - it is expected that once conditions are met, they will see it.

Your proposal moves group members only from type 1 to type 2. Ie - by setting the group members only as just another condition it becomes impossible to distinguish between the students who will never see the activity, and those who will probably see the activity once conditions are met. This is important because there are interfaces (like in mod_assign) where we need to list all of the students who are participants in an activity - this needs to consider all of the type 1 conditions, but not the type 2 conditions. This also needs to be fast (sql joinable) and work for a list of users, not just the current user.

I also need to manage expectations a bit and say that this work is being done too late in the cycle to be considered for 2.7 - but now is the correct time to be working on such a major feature for 2.8.

Average of ratings: -

Permalink | Show parent | Reply

(I've also discussed this with Martin D in chat. Thanks both!)

It looks like the situation - from Martin - is that we need to either delay this feature, or else just the groupmembersonly removal part of it, from 2.7 until 2.8. I'm currently thinking about whether it is sensible to remove the groupmembersonly-related changes.

Of course that adds more work and means I won't be ready to submit the feature until even closer to the code freeze... We also would probably need to remove the group and grouping restrictions from this feature (leaving them in groupmembersonly) to avoid user confusion by having two interfaces to do the same thing. Or I guess they could be left in the code but disabled behind another experimental setting. So basically I'm not sure whether this is feasible given the rest of the work I haven't finished yet - i.e. I probably have time to finish it, or time to change it to remove group-related stuff, but probably not both. I think it might be better to move the whole thing to Moodle 2.8. On the other hand, because of the way Moodle development works there is a huge gap between 2.7 and 2.8 development during which the code will rot and this will make significant extra work... So I'm still thinking about it.

The rest of this I somewhat agree with (I already have a solution for it vaguely planned). However, I do want to make a few points:

1. The current situation is not as rosy as implicitly suggested, since there are existing conditions which should be type 1 and are presently handled as type 2. For example, if you set a user profile condition like 'Department = Maths' that should be a permanent condition.

2. There are very few places which actually implement the groupmembersonly condition in lists of users like that (even though more probably should do).

3. I will implement a solution that I think people will be happy with HOWEVER it will still not be a perfect solution.The perfect solution is impossible with Moodle as it stands (and probably even in theory) because there are several ways other than availability conditions to restrict access to modules, and also some conditions could be either permanent or temporary (we can't tell).

Here's what I am proposing:

Within the availability API, there will be a way for condition plugins to indicate whether they are 'permanent' or 'temporary' conditions.
Permanent conditions will need to provide a method to check that condition that can be done in bulk for a list of users and does not rely on individual user modinfo.
Temporary conditions (= anything that actually should be temporary, + anything that can't efficiently be checked in bulk) will be ignored for the purpose of this list. (By 'ignored' I mean that if the condition is 'User must have TEMPORARY CONDITION' then it passes. But also, if the condition is 'User must NOT have TEMPORARY CONDITION' then it still passes too.)

As you can see, it will be easy with this API to replicate lists of users for group and grouping conditions, including more complex ones that are not supported with current groupmembersonly. (E.g. 'User must belong to GROUPING A or GROUPING B', 'User must belong to GROUPING A but must not belong to GROUP X'.)

--sam

Average of ratings: Useful (2)

Permalink | Show parent | Reply

Hello Sam,

as I said, don't envy you sounds tricky.

Looking at it from the outside here, with teacher hat, student in mind and ease-in terms of UI, navigation and choices, it seems to me that it would be a real improvement to have the following in 2.7 (of course, if do-able) if not then as you say 2.8-in the first instance:

-to have pluggable conditions

-an improvement in the default form

selecting groups/ings and restrict access ( I am hoping I have picked up on that as being the group stuff)- could this not follow in the future....in some shape or form, over time?

Forgive me, this is not a techy response-more of a pragmatic one...which I hope is helpful

cheers,

Dawn

Average of ratings: -

Permalink | Show parent | Reply

Thanks for comments. To update on this, and based on the previous discussion with Martin, I am now aiming to submit a version of this change for Moodle 2.7 although that is subject to Moodle HQ reviewing and accepting it. (I aim to submit it by end of next week which is before the stated code freeze on 4 April.)

The planned version:

Does not contain any modification to groupmembersonly - everything using groupmembersonly will behave exactly as at present. (That is to say, it will be broken in lots of ways that nobody much has noticed.)
- This reduces the scope of the change by a reasonable chunk, i.e. it is basically confined to library files apart from a few small cases where I moved a function, and doesn't affect individual modules etc.
Does contain support for 'bulk' checks for permanent access conditions when listing users, as outlined above, although this will not be used initially by other areas of code. (Obviously the long-term intention is that this API would be used in places that previously call groupmembersonly-specific APIs, but as above, I won't be switching any code to actually use it.)

The group/grouping availabilty conditions from the new system will be available for sections (which don't have groupmembersonly and don't have code all over the place using them).

I will make it so you can't add group/grouping availability conditions for modules. (I was thinking about leaving them on if groupmembersonly is disabled, but that might possibly confuse. A bit up in the air. Would be easy to change later anyhow.)

I was hoping to make a screencast this evening demonstrating the feature, but making all the changes above has obviously set me back by about a day, so it's not quite ready to show yet. Maybe Monday evening!

--sam

Average of ratings: -

Permalink | Show parent | Reply

Just a thought: since 2.7 will be LTS release and we will be "stuck" with it for a bit longer - wouldn't it make sense to spend more time preparing it? For example... release it half a year later (when 2.8 normally would).

Tomek

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Hi Tomasz and all,

It does appear, there is good reason to focus in depth on the release of 2.7 from where I am standing, given the important ramifications tied up with Sam's work here (although don't ask me to paraphrase the agenda-because my message will end up being longer than Sam's post-I dont have the language ).

So, in true style logic-process-an all, the question remains: What are the reasons for not releasing 2.7 later?

Just a thought (probably an obvious one )

cheers,

Dawn

Average of ratings: -

Permalink | Show parent | Reply

There is ALWAYS another feature or ten just over the horizon, and that will never change.

It's best not to mess with the established timetable, too many depend on it now. Better to just get on with getting those new features into the next available release.

Don't get too hung up on the LTS release. Even though it's getting bug fixes for three years it's still going to be completely out of date by that time and I really expect most people to keep upgrading.

Back on topic: great stuff, Sam.

Average of ratings: Useful (1)

Permalink | Show parent | Reply

I made a blog post including a screencast (which you have to download if you want to watch it, rather than playing directly, because reasons). This is to demonstrate the new UI.

Very nearly finished with code now...

--sam

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Sam, I watched the video and the UI is much better now and the ability to do nested and more complex conditions is going to be amazing. Some comments:

You are hard coding the word "Student", but we, and I believe many others, use Moodle for more than just courses with students. We have on-campus working groups and staff use the system as well. What if you just use the more generic term "Participant" (similar to how there is a Participants list)?
I was really confused by the "eye" icon and was wondering what it mean until you got around to mentioning it. Before you explained it, I thought it was a status indicator if the condition was met or not. Don't know what to do to improve it.
When you add a new condition it automatically says "Invalid", which is potentially upsetting to the user using it. What if the initial state is "Please set the condition" or something friendlier? Then if the user chooses an invalid condition then display the "Invalid" message?
I really like the restriction picker. However, some notes:
1. For "Activity completion", I feel it should be more obvious that it refers to another activity. What about you word the sentence "Require participants to complete (or not complete) another activity"?
2. For "Date" the wording says "until" and "after", but in the demo the dropdown state for Date is "from". Can the wording be made consistent?

I am hoping this gets to 2.7, since we will be on that version for at least the next 2 years.

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Excellent screencast Sam! Rex makes some really good points. I personally love the 'eye' icon instead of the cumbersome wording. I agree that 'invalid' would confuse people and that it should be something else - like as Rex says "please set condition" and I note you are thinking of changing "condition group/group of nested conditions"' which is good, because I think that also could confuse people since it is not connected to groups. Maybe "set" would work.

Average of ratings: -

Permalink | Show parent | Reply

Thanks Mary! I changed the wording about the set - it's now referred to as 'restriction set' (which is good because I called them restrictions, not conditions, in other places.)

--sam

Average of ratings: -

Permalink | Show parent | Reply

Thanks for watching! Here are some responses:

1. I think it's officially okay (Moodle policy) to use the word 'student' in language strings within the editing interface, to simplify matters. (None of this interface actually appears to students, remember. Er. To participants...) Could somebody correct me if I'm wrong and another word is preferred, Mary maybe? This is another case where friendliness won over accuracy - the restrictions might apply to other people who aren't students, it depends on your role setup etc.

2. The eye icons are a bit confusing but are quite fully explained by the popup tooltip, and are elegantly small at least. It may not matter too much as the default (visible) is probably okay most of the time. By the way, if you mean you couldn't tell it was supposed to be an eye, sorry but these are default Moodle theme show/hide icons, feel free to override in your theme.

3. Agree, but your text is probably a bit long - I've changed it to 'Please set'. (I don't want to do logic for different times it appears, don't think this is needed,)

4. Agree with both points, have fixed these.

--sam

Average of ratings: -

Permalink | Show parent | Reply

Regarding using the word 'student' in language strings, from http://docs.moodle.org/dev/Help_strings:

The following words should be used in the en help strings whenever it is necessary to refer to people with particular roles in a generic sense.

Participants - all people with a role

Teachers - people with some sort of a facilitation/editing role

Students - people primarily there to learn

Users - people across the site

Average of ratings: -

Permalink | Show parent | Reply

Sam, hi

brilliant...as you are- nearly there....nothing to add here.

HH

Dawn

Average of ratings: -

Permalink | Show parent | Reply

Hi Sam,

Thanks for the screencast and the development of this feature, which is quite a progress

Some thoughts about the wording of the strings. Since I translate the Moodle interface in french, I'm a bit concerned about some potential problems when translating this. Some of my notes may be irrelevant, as my english is quite imperfect.

The phrase "Student [must|must not] match [all|any] of the following" should be improved. If I understand correctly, a student cannot match a date (in french at least, this is the case). I'll suggest something like "[All|Any] of the following conditions [must|must not] be fulfilled (or met?)".
In the same phrase, the string parameter [All|Any] in the combination with "of the following" could pose problem, as the wording is (en french at least) not the same with "all" than with "any". In french, "all of the following" is "toutes les conditions suivantes", but "any of the following" is "une des conditions suivantes" (notice the change of the article "les" -> "des"). I didn't look at your code, but I suggest that the strings and their parameters allow for such constructs.

Thanks again, and cheers,

Nicolas

Average of ratings: Useful (1)

Permalink | Show parent | Reply

Hi,

Thanks Sam for the screencast, and this great extension of this feature. It's really better in several ways : UI (just showing what is needed), functionnalities

I also agree with Rex and Nicolas's suggestions.

Hope this will be in 2.7.

Séverin

Average of ratings: -

Permalink | Show parent | Reply

Thanks for your comments!

Regarding whether a student can match a date, technically you are correct, but I think that's semantics and it's easily comprehensible as-is. I did think about it a bit and I think the current wording is a pretty good compromise between friendly language and accuracy. When you make it more accurate, it tends to become longer and harder to understand or have programmer-ish text...

Regarding the translation - it works like this depending on whether there is only one dropdown (single condition that you can choose NOT or, er, not) or two:

X [dropdown] Y [dropdown] Z

or

X [dropdown] Z2

You can change strings X, Y, and Z/Z2 and the text of the dropdowns. Seems reasonably flexible regarding different orderings etc, correct me if wrong.

(By the way there are actually hidden labels for accessibility as well, which possibly complicates matters slightly.)

--sam

Average of ratings: -

Permalink | Show parent | Reply

Hi,

Thanks for your answer. According to your description, this seems indeed flexible enough.

PS. In french, you absolutely can't say that somebody match a date. It sounds somewhat strange. I'll find a way to translate this adequately.

Cheers,

Nicolas

Average of ratings: -

Permalink | Show parent | Reply

Just to update, the code is finished (ish) now - anyone particularly adventurous who knows how to use Git etc, you can try it out via the link in MDL-44070. (Don't run this code on anything other than a disposable test database - there's no way to go back from the database changes short of wiping the whole database and reinstalling Moodle.)

I am still working on automated interface tests over the next few days (the back-end unit tests are comprehensive, finished, and working, but I need to do the Behat UI tests). These might reveal bugs of course...

I don't know whether there's any chance of this getting into Moodle 2.7 or not. HQ developers and Martin have the decision on that - I've done my best! If it doesn't get into 2.7 I hope it can at least be one of the very first features included when 2.8 development begins.

--sam

Average of ratings: -

Permalink | Show parent | Reply

It would appear that it isn't possible to set what used to be called "showavailability" anymore (or at least I can't find it).

This controlled whether or not the activity/section was displayed at all or if it was "hinted" at by displaying the conditions that have to be met.

This now means that every activity/sections always has some sort of visiblity, which means if you are using groups (or any other restriction) to hide elements from certain groups of students the whole thing doesn't work.

I've raise a bug in the tracker as this is a pretty major change (IMHO it is a bug): https://tracker.moodle.org/browse/MDL-45449

Is it possible that there simply hasn't been a UI / Restriction condition implemented in the Javascript control to replace the old "static" yes/no drop down in the Moodle form?

Average of ratings: -

Permalink | Show parent | Reply

In the documentation it says you can click the eye -see http://docs.moodle.org/27/en/Conditional_activities_settings Is this what you mean?

Average of ratings: -

Permalink | Show parent | Reply

When the eye is shut and the student meets the conditions the activity is shown but the conditions are also shown. This is a change in behaviour from 2.6 "Hide activity entirely in the course and gradebook" to 2.7 eye shut.

Is there a way to just show or hide the activity based on the conditions but not show the conditions to the student?

Average of ratings: -

Permalink | Show parent | Reply

In regards to availability. Would it be hard to do time limits?

Like a student takes exam 1 but exam 2 will not become available until 12-24 hours after he finished exam 1.

with regards

Davíð

Average of ratings: -

Permalink | Show parent | Reply