Moodle

Nadav - Thanks for sharing the patch which is a good start. I think it might even by more useful if we could make it use the user filtering code. I am attaching a screenshot and a diff file (which does not work - see the TODO) but gives an idea of what I am thinking. Feel free to play around with it. I think it would greatly increase the flexibility of what you can do with filtering the users. I will also tag this as a usability issue since we need to be consistent with user lists. Having the ability to use filters makes sense here IMO. Peace - Anthony

Olli - I added you as a watcher as this is another example of consistency in terms of how we handle selecting the list of available users for a given operation. I think using the filter should be default. Peace - Anthony

I'd also really like to be able to modify the search criteria used when adding users (students in my case) to a course. Initially it would be nice to just increase the database fields that are included in the search to include the username and/or idnumber. The features outlined in this patch are an additional step forward but I cannot, unfortunately, get it to work on 1.9.4+

Jason

i totally agree with you (Anthony) it is better we use the filtering code.
especially to make it a more versatile (ability to choose fields)
and unified (UI consistency) solution across Moodle.

Jason@
the original code (assign.php) was changed in version 1.9.4+ so the patch does not apply (cleanly)
and should be changed a little ( i guess ) to be useful for that version.

this is a patch for 3 different files agenst HEAD (moodle dev version 2) that adds
users filter to assign roles page (dialog)

it is ready for Moodle 2 and should not be applied (directly) to moodle 1.9.x branch
as the original patch was !!!

this patch needs some code review

Anthony - i took you suggestion and managed to make it work for the Moodle HEAD (v 2.0)
instead of trying to fix my old and very limited patch (i suggested previously) for version 1.9.x

do you think i (we) should make an effort to backport it for the 1.9.x branch too ?
( i just guess we be all moving to v2 soon ? )

Nadav - Thanks for your work on the patch. I would say if you can definitely provide a 1.9 patch for folks who may need it. I think it is going to be a while until Moodle 2.0 is ready and many places may wait a while before adapting it. Let me know when its ready and I'll give it a little testing. Peace - Anthony

Hi Nadav and Anthony
I have version 1.9.4 installed and would also be happy to test a filter-solution for the role-assignment. It's really an important improvement
Ole

OK, 194 patch is ready for testing... it was easier then i thought. eventually.
although the two version (1.9.4 and 2.0) are very much different (amazing)

you need to apply this patch to only one file : admin/roles/assign.php
i am attaching a new file: assign.php.194.diff

role assign dialog - users filter patch
for moodle version 1.9.4

Thanks Nadav - I'll take a look at this tomorrow. Peace - Anthony

Nadav - The problem with my suggestion about the filters is that it actually does not resolve this issue. I think we need to have a place to configure what fields are shown and then use that to construct the array found in /user/filters/lib.php around line 35.

if (empty($fieldnames)) { $fieldnames = array('realname'=>0, 'lastname'=>1, 'firstname'=>1, 'email'=>1, 'city'=>1, 'country'=>1, 'confirmed'=>1, 'profile'=>1, 'courserole'=>1, 'systemrole'=>1, 'firstaccess'=>1, 'lastaccess'=>1, 'lastlogin'=>1, 'username'=>1, 'auth'=>1, 'mnethostid'=>1); }

I wonder what the relationship between this array and the array that Moodle builds for user profile settings at admin/settings.php?section=userpolicies (Users->Permissions->User policies) - i.e., $CFG->hiddenuserfields. It would seem that institution, department and probably some other fields (like address) need to be added in to the array. In fact by default, I would suggest getting a list of all the fields and removing those that are not needed.

Does this sound reasonable, make sense? It is late for me so my brain has already started shutting down. Peace - Anthony

In this patch, I have added department, institution, idnumber, and address to the list of filterable fields. To add them required not only adding them to the array but also creating the case scenarios. I still think we can use the hiddenfields here and the array not having those fields would take care of not displaying them. I am not sure if it would be possible to manually type the URL and get the results one wants. We should probably do a little more checking on capability to view and search on particular fields. I have not considered roles/capabilities in this patch and am too tired to do so right now. But if we at least add the institution and department to the list then this issue could be resolved but as mentioned before I think we should make sure that we have all the fields that we really want. Peace - Anthony

you are soooo right i was not noticing that it was missing
some very important fields until i had to use them myself today

please patch the patch and add:
$fieldnames = array('realname'=>0, 'lastname'=>1, 'firstname'=>1, 'email'=>1, 'city'=>1, 'country'=>1,'institution'=>1, 'department'=>1 ,'address'=>1,
'confirmed'=>1, 'profile'=>1, 'courserole'=>1, 'systemrole'=>1, 'firstaccess'=>1, 'lastaccess'=>1, 'lastlogin'=>1, 'username'=>1, 'auth'=>1, 'mnethostid'=>1);

and inside the get_field() function after the line that handles 'city' (inside the case statement) add these lines too:

case 'institution': return new user_filter_text('institution', get_string('institution'), $advanced, 'institution');
case 'department': return new user_filter_text('department', get_string('department'), $advanced, 'department');
case 'address': return new user_filter_text('address', get_string('address'), $advanced, 'address');

and we should definitely check if some more fields are popular too ?

Nadav - You will see that the last patch I uploaded (http://tracker.moodle.org/secure/attachment/17101/MDL-17780.patch) should include institution, department, address, and idnumber both in the list of fields and in the case statements. I really think we need to look at all of the fields in mdl_user. I could see that it would be beneficial to have the following fields which are not included in this patch:
policyagreed (if an admin wants to see which users have not agreed to site policy, not useful for assigning roles), icq, skype, yahoo, aim, and msn which I think should really be broken out into separate tables (mdl_instantmessengers [id, type] and mdl_users_instantmessengers [id, userid, imid]), lang (for searching for users by preferred language), theme (to see which users are using a particular theme and notify them if it is going to be removed or updated), timezone (notify users that are likely to be affected by an outage or maintenance), url, and description. The other settings I find myself using less (for example, mail format, etc.) but in theory system admins might want these. So I think it really needs to be a comprehensive listing. Peace - Anthony

Olli - I think that the ability to add a filter would be really helpful in the messaging search. Are there other areas where we ought to make use of the ability to apply filtered search conditions? Peace - Anthony

i have also added this (latest user filter) patch to the Participants page (Moodle v2)
(should i open a new issue tracker for this ?)

to apply it, open user/index.php and add to the begging of the file the following line:

require_once($CFG->dirroot.'/user/filters/lib.php');

and around lines 530 add the following (inside the remarks !!!)

$table->initialbars(true);
    $table->pagesize($perpage, $matchcount);

///////////////////////////////////////////////  patch starts here
$wheresqlfilter = '';
// pressing the 'add filter' button, reloads the assign role page 
// so i have to pass contextid and roleid to the user_filtering class
// if i do not want to be kicked out of this page with... contextid missing error :-)
$ufiltering = new user_filtering(null,null,array('contextid'=>$context->id,'roleid'=>$roleid));
// add filter's buttons
$ufiltering->display_add();
$ufiltering->display_active();
// split filters into SQL WHERE clause and 'should be filled in' params
list($wheresqlfilter,$sqlparams) = $ufiltering->get_sql_filter(); 
// replace :LABELS with actuall filters
foreach ($sqlparams as $sqlparamkey => $sqlparam) {
  $wheresqlfilter = implode("'".$sqlparam."'" , explode(':'.$sqlparamkey,$wheresqlfilter));
}

if ($wheresqlfilter != '') {
  $wheresearch = " AND ".$wheresqlfilter;
}
///////////////////////////////////////////////  patch ends here

    $userlist = $DB->get_recordset_sql("$select $from $where $wheresearch $sort", $params,
            $table->get_page_start(),  $table->get_page_size());

i did not disable or removed the Initials alphabet filtering just added this Userfilter on top of it
but i guess it should/could be removed ? (since it looks like a duplicate functionality)

Nadav - I think it would be helpful to create a separate issue. You can mark it as being related to this one but I think it is good to keep bug reports focused on a single issue. Thanks for your work and contribution on this issue. Peace - Anthony

Thanks Anthony – added this to http://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency#Interaction_styles.2Felements_to_possibly_examine and will consider it for the guidelines. Seems important enough, though.

i am backlinking the new issue i made for Participants page
http://tracker.moodle.org/browse/MDL-19285

Hi, I added similar patch for user filtering in CONTRIB-2387.