Design review please - ajax user selector to make assigning roles and so on easier

Design review please - ajax user selector to make assigning roles and so on easier

por Tim Hunt -
Número de respuestas: 11
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers
Development:Ajax_user_selector

Does the interface sound OK? Does the code architecture seems sensible? Thanks.
Promedio de valuaciones (ratings): -
En respuesta a Tim Hunt

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Jeff Forssell -
Sounds good- (The little that I understand thoughtful )

The link at the bottom of the page (to a discussion thread) goes to XXX.
Is it supposed to go here?
Promedio de valuaciones (ratings): -
En respuesta a Tim Hunt

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Dan Poltawski -
I like it and I was just about to mention a related feature request which several people have asked me about recently (searching the list of users assigned), but looking at the code it seems you've already implemented it sonrisota
Promedio de valuaciones (ratings): -
En respuesta a Dan Poltawski

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Hans de Zwart -
Just we received a request from a client to develop some code which would enable them to search the left side of the role or group assign interface.

If I understand Dan correctly this will be available in the 2.0 user selector?
I couldn't find any info about this in the http://docs.moodle.org/en/Development:Ajax_user_selector page...
Promedio de valuaciones (ratings): -
En respuesta a Hans de Zwart

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers
Yes, this is done in HEAD. I did not update the page you linked to, because I forgot about it. It was really useful for me to write it all down before I started writing code, but this is just part of a larger body of work and I only remembered to updated that other page.

You can probably take the code from HEAD and back-port it to 1.9 quite easily. The selector widget in is user/selector and does not fundamentally do anything that will not work in 1.9. You just need to undo all the Moodle 2.0-isms (like accessing the database via $DB->). There is a lot of PHP and JS there that is worth reusing.

You will also need to change admin/roles/assign, but there you will need to separate out my changes to use the new widget from the other chagnes that are more integrated with my other 2.0 work.

Finally, you will have to deal with the fact that I was intentionally trying to clean stuff up as I went along, so you will encounter things like new weblib functions that I created and then call.

Remember that the tracker will show you what chaned for a particular issue on the Version Control tab, although with MDL-16966 they are split over a number of subtasks.
Promedio de valuaciones (ratings): -
En respuesta a Tim Hunt

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Matt Gibson -
Hi Tim,

I'm only a novice with JavaScript, so can't comment further than to say that I like the look of the interface (although I can't try it yet without upgrading PHP). I was confused though by the bit in the docs about AJAX security (below) - how does it work? I've written my own AJAX stuff to deal with security using require_login() and then a permissions check based on geting the context based on course or module id. Does the hash work in place of these?


Excerpt from your docs page to save others hunting for it:

Security

One issue with ajax interfaces is how you check permissions in the context of an ajax request, which often gives you very little context at all. Therefore, when a user_selector is displayed, a $selectorid hash code will be generated depending on the subclass name, the control name, and any options. At the same time, we will store the information about this user_selector in the session: 

$USER->userselectors[$hash] = array(
 'class' = 'my_user_selector',
 // Probably some other values storing the options.
);

Then the ajax requests will go to a php file passing options ?selectorid={selectorid}&sesskey='{sesskey}'.


Promedio de valuaciones (ratings): -
En respuesta a Matt Gibson

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers
OK, so if you have a web page making ajax requests, it is going to be sending HTTP requests like http://example.com/moodle/user/selector/lib.php?some_parameters, and Moodle is going to be responding with data, which may be quite sensitive personal data of users.

And there is nothing to stop someone working out a URL like http://example.com/moodle/user/selector/lib.php?some_parameters, and typing it directly in their web browser. So we had better be sure that only people with appropriate permissions get a response from that URL. Everyone else should get an error.

That means that some_parameters had better include, not just enough parameters to specify the data that the user wants, but also, enough information that we can determine whether or not they should be allowed to access that information.

Now one issue is performance. Loading some courses and contexts, and doing some has_capability calls is Moderately expensive. Particularly with an Ajax search-as-you-type, you may be going to be processing a whole bunch of similar requests in quick succession for the same user, so it is a pity to have to redo all that checking, especially when you already did it before generating the page that contains the Ajax control.

But for the user selector control, there is a more significant problem. This is meant to be a generic control that can be sub-classed for different situations. Therefore, the base class, which handles the low-level stuff does not even know what data is needed to initialise a particular instance, nor what security checks need to be performed.

Therefore, the approach I took is that:
  1. All security checks should be performed when the control is printed.
  2. Then, all the information needed to initialise the search is stored in the user's session as a PHP array, and associated with a token string.
  3. The some_parameters is basically just token=XXX.
  4. search.php looks to see if token is in the current user's session, and will only send back data if it is. From the token, it can get everything it needs.
At this point it is probably best if I just direct you to the code. Start with cvs:user/selector/search.php, which does the searching. That is quite simple.

Then you need to look at where the control is output. This is in cvs:moodle/user/selector/lib.php, which is long, but to understand this bit, you only need to look at funciton initialise_javascript, which is called by the display method, and which relies on get_options to get the configuration information from the subclass.
Promedio de valuaciones (ratings): -
En respuesta a Tim Hunt

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Matt Gibson -
Thanks Tim, that's really helpful. It makes a lot more sense than the way I've been doing things!

Off to look at the code now to see if I can adapt any ideas sonrisa
Promedio de valuaciones (ratings): -
En respuesta a Tim Hunt

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Martín Langhoff -
Only saw this now (oops!) -- I think it all makes sense to me, except that I don't have a clear picture of whether you had very large scale sites in mind.

Chances are you did - people at OU will beat you up otherwise parpadeo - but I do wonder how you deal with very large listings of users. Besides saying "All potential users (8 million)", what happens when the user clicks to actually request to see the 8M users? Server OOMs? The interpipes clog? Client segfaults/OOMs? Something paginates the dataset in edible chunks?

Promedio de valuaciones (ratings): -
En respuesta a Martín Langhoff

Re: Design review please - ajax user selector to make assigning roles and so on easier

por Tim Hunt -
Imagen de Core developers Imagen de Documentation writers Imagen de Particularly helpful Moodlers Imagen de Peer reviewers Imagen de Plugin developers
It refuses to show you any actual users at all, until the number matching the search is small enough (down to 100, it used to be 5000 in 1.9, with ajax, being told to keep searching is less irritating). The sequence of messages look like

Too many users (543255) to show
Please use the search

Too many users (1735) match 'Ti'
Please search some more

Potential users matching 'Tim' (17)
Tim Hunt, ...
Tim Jones, ...
...

Also, now, by default, the searching does ILIKE 'Ti%', which increases the chance the database can use indexes, although Martin (D) insisted that I add an option to search ILIKE '%Ti%'. (You need that if you are searching emails by domain.)


So, yes, I thought about it, but I have not yet tested it with a huge DB. (Even though generator is now in core.)
Promedio de valuaciones (ratings): -