Tim Hunt

Thanks to a certain demanding question type author, question type plugins now have their custom CSS and JavsScript included on the question editing page as well as on the quiz attempt page. MDL-18711 for details.

A bit late in the day, I know, but I have just thought of another good GSOC project. There are to bits of roles administration interface that would be really useful, but which we don't have yet:

MDL-17068 is an easy way to associate parents/mentors with students.

MDL-10002 (19 votes!) is a user-centric way to assign roles to a user. That is, one place where you can assign or un-assign roles to a user in many different contexts.

Both of these are about making new bits of user interface. They don't require low-level changes in the roles library.

I think together they would make a nice project, and one that would make a lot of admins very happy.

This is basically a cross-post of http://moodle.org/mod/forum/discuss.php?d=119665 / MDL-18669. Just thought people here might care.

Note, I am not changing how get_string works, I am just changing the internals.

I have been playing around with refactoring get_string, since the code in there was a bit of a mess, with quite a lot of duplication, and some complicated logic that I was not sure was correct.

The results are in MDL-18669, including a patch against HEAD.

Included in the patch is a new script lib/simpletest/getstringperformancetester.php. That does some simple performance measurements on get_string. On my system, my new code it a little bit faster than the old code (by about 4%).

However, I now have some doubts about whether that testing script is really measuring the right thing. It is getting the same string from the same file 20000 times, wheras typical Moodle pages get a lot of different strings from a few different files.


So, really, I would like to ask you to do two different things, if you have the time and inclination:

1. Apply the patch to your HEAD install, and run the test script. Then switch back to the un-modified moodlelib.php, and get the same timings for the old code. Please report how the times change, and what sort of hardware and OS you are using.

2. Review the test script, and if you think we should be measuring something else, please make suggestions. (Feel free to edit the script if you like.)

Several people have said that the roles system is so complicated that the function get_users_by_capability cannot be implemented purely in SQL. Well, I think I have just worked out they are wrong: SELECT DISTINCT userid FROM ( SELECT ra.userid, rc.capability, 100*actx.depth + octx.depth AS weight, SIGN(SUM(rc.permission)) AS combinedperms, MIN(rc.permission) AS prohibits FROM ( SELECT userid, roleid, contextid FROM m_role_assignments WHERE contextid IN (1,35,36,37,47) UNION SELECT id AS userid, 7 AS roleid, 1 AS contextid FROM m_user UNION SELECT id AS userid, 12 AS roleid, 2 AS contextid FROM m_user WHERE 2 IN (1,35,36,37,47) ) ra JOIN m_context actx ON actx.id = ra.contextid JOIN m_role_capabilities rc ON rc.roleid = ra.roleid JOIN m_context octx ON octx.id = rc.contextid WHERE rc.capability IN ('mod/forum:replypost', 'moodle/site:doanything') AND octx.id IN (1,35,36,37,47) GROUP BY userid, capability, weight ) combined_permissions GROUP BY userid, capability HAVING MIN(prohibits) > -1000 AND MAX(weight * combinedperms) > -MIN(weight * combinedperms) That is get_users_by_capability(get_context_instance_by_id(47), 'mod/forum:replypost') on one of my test servers where the prefix is 'm_'. Some explanation of the magic numbers appearing in there:

• 100 simply needs to be any number that is greater than SELECT MAX(depth) FROM m_context;
• 1,35,36,37,47 is derived from get_context_instance_by_id(47)->path which is '1/35/36/37/47'
• 7 is $CFG->defaultuserroleid
• 1 is the system context id get_context_instance(CONTEXT_SYSTEM)->id
• 12 is $CFG->defaultfrontpageroleid
  
• 2 is the front page context id get_context_instance(CONTEXT_COURSE, SITEID)->id
• -1000 is CAP_PROHIBIT

At the moment this skips a lot of the optional parameters get_users_by_capability, but they can all be accommodated by easily using the same sort of extra joins and where clauses that are already used in get_users_by_capability.