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

have put vote in tracker for this triaged feature

Dawn

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

(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

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

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. 

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:

1. 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)?
2. 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.
3. 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?
4. 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.

Sam, hi

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

HH

Dawn

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

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