If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Student projects/User Management Improvements

From MoodleDocs



This project is part of the 2007 edition of Google Summer of Code (GSoC). Mentor: Yu Zhang. Student: Andrei Bautu.

The objective of this project is to improve usability of user management features in Moodle. The main working directions established in the GSoC 2007 proposal are:

  • Improve the User features in moodle to allow bulk-operations.
    • Create an interface to do bulk operations on users (e.g. delete users, reset passwords etc) This could potentially use an AJAX implementation for multiple filtering/selection of required students for bulk operations.
    • Overhall the CSV upload features to allow more flexibility (more options, features to auto-generate more fields such as usernames)
  • Enrolment
    • Specify time of manual enrollments (MDL-8877)
  • Notes
    • Allow teachers to put notes for each student in every course, much requested feature

Working on the original goals, other possible improvements were noticed by the mentor, the student and other Moodlers:

  • Enrolment
    • Limit enrolment for students (from unlimited to limited time)
    • Extend enrolment for students (from limited to unlimited time)
    • Allow extend/limit operation for a group of users
    • Allow extend/limit operations even on courses with unlimited enrolment period
    • Extend/Limit period based on various reference dates (course start date, student enrolment start and end date, course enrolment start and end date, day of operation)
    • Set enrolment period end date to an absolute date
    • Allow setting enrolment period end date for a group of users
  • Reusable user filter
    • Allow to filter users by username, first and last name, location
    • Allow to filter users by custom profile fields
    • Allow to filter users by enrolment into courses
    • Allow complex filters to be created and set simultatiously
  • Note: additional suggestion added to page comments

Database structures

This project does not require extra database tables. The only objective that requires information to be stored in the database is Notes, for which we use the existing Post table.

Core functions


A note object has the following atributes:

  • $id - the identifier of the note (NULL if the note has not been saved yet)
  • $courseid - the identifier of the course in which the note is posted
  • $userid - the identifier of the user the note is about
  • $content - the text of the note
  • $format - the formatting type of the text of the note (e.g. FORMAT_PLAIN, FORMAT_HTML)
  • $created - timestamp of creation date
  • $lastmodified - timestamp of last modification date
  • $usermodified - the identifier of the user that modified the note last
  • $publishstate - one of the constants NOTES_STATE_DRAFT, NOTES_STATE_PUBLIC, NOTES_STATE_SITE with the following semantics
    • NOTES_STATE_DRAFT - note is visible only to its author, and only in the course in which it was posted
    • NOTES_STATE_PUBLIC - note is visible to users with notes:view capability, only in the course in which it was posted
    • NOTES_STATE_SITE - note is visible to users with notes:view capability in all courses (above the course-specific notes)


Inserts a new note or updates an existing one in the database a note depending on $note->id. The $note object is passed by reference and its id will change to match the data in the database. If the rating of the note is 0 (i.e. don't care) it will be changed to 3 (normal). The created, lastmodified and usermodified attributes are updated as needed.


Deletes the note with the id $noteid.


Returns a note object coresponding to the $noteid id.

'&note_list($courseid, $userid=0, $state = , $author = 0, $order='lastmodified DESC', $limitfrom=0, $limitnum=0)

Returns an array of note objects from the specified course, for the specified user, in the specified state, created by the specified author, ordered by some criteria.


Returns the human-friendly name for the specified state (i.e. personal, course or site).


Returns an array of human-friendly names for note states indexed by the state codes (i.e. personal, course or site).

note_print($note, $detail = NOTES_SHOW_FULL)

Prints a note object with the specified details (ORed values): NOTES_SHOW_HEAD, NOTES_SHOW_BODY, NOTES_SHOW_FOOT. The constant NOTES_SHOW_FULL means show all details.

note_print_list($notes, $detail = NOTES_SHOW_FULL)

Prints a list of note objects (e.g. as fetched by note_list) with the specified details.

note_print_notes($header, $addcourseid = 0, $viewnotes = true, $courseid = 0, $userid = 0, $state = , $author = 0)

Retrieves and prints a list of note objects with specific atributes. It uses note_print_list to display the list.

  • $header is HTML to print above the list
  • $addcourseid id of the course for the add notes link (0 hide link)
  • $viewnotes true if the notes should be printed; false otherwise (print notesnotvisible string)
  • $courseid id of the course in which the notes were posted (0 means any)
  • $userid id of the user to which the notes refer (0 means any)
  • $state state of the notes (i.e. draft, public, site) ( means any)
  • $author id of the user who modified the note last time (0 means any)

Reusable user filter

A reusable filter component (located in moodle/user/filters) has been developed which can be used to filter users (as well as other database information). The filter component uses various filter types to allow the user to define complex filtering criteria as a list of ORed logical clauses. The filter builds an SQL WHERE clause using defined criteria and other (static) clauses.

Filter form

The filter component is implemented in the class user_filter_form, a subclass of MoodleQuickForm. This allows it to be used with only a few lines of code.


// prepare some filter types (each filter must have a unique name, i.e. first parameter of the constructor)
$filters[] = new user_filter_text('username', get_string('username'), 'username');
$filters[] = new user_filter_text('realname', get_string('fullname'), sql_fullname());
$filters[] = new user_filter_text('email', get_string('email'), 'email');
// create the user filter form
$user_filter_form =& new user_filter_form(null, $filters);

// (re-)display the user filter form 

if ($user_filter_form->is_submitted()) {
  // get the SQL filter (additional conditions: not a quest (id=1) and not deleted)
  $where =& $user_filter_form->getSQLFilter('id<>1 AND NOT deleted');

  // count or retrieve users
  $ausercount = count_records_select('user', $where);

getSQLFilter($extra=) Returns the complete SQL WHERE condition coresponding to the active filters and the extra conditions supplied to the method. The parameter $extra may be an array of SQL where conditions to be conected by ANDs or a string SQL where condition, which will be connected to the active filters conditions by AND.

Defined filter types

user_filter_text - Generic filter for text fields.

user_filter_text($name, $label, $field, $value=null, $operator=0)

user_filter_select - Generic filter based on a list of values.

user_filter_select($name, $label, $field, $options, $value=null, $operator=null)

user_filter_radios - Generic filter with radio buttons for integer fields.

user_filter_radios($name, $label, $field, $options, $offoption=true, $value=null)

user_filter_yesno - Generic yes/no filter with radio buttons for integer fields.

user_filter_yesno($name, $label, $field, $value=-1)

user_filter_profilefield - User filter based on values of custom profile fields.

user_filter_profilefield($name, $label, $field='id', $value=null, $profile_field=0, $operator=0)

user_filter_courserole - User filter based on roles in a course identified by its shortname.

user_filter_courserole($name, $label, $field='id', $value=null, $categoryid=0, $roleid=0)

user_filter_globalrole - User filter based on global roles.

user_filter_globalrole($name, $label, $field='id', $value=0)

Custom filter types

A filter type object has extends the class user_filter_type, providing/overriding implementations for the following methods:


Returns the condition to be used with SQL WHERE (e.g. country = 'RO')


Retrieves data from the form data and sets up the filter.


Adds specific controls to the MoodleForm $mform and (optionaly) sets them values to match the filters internal state.


Returns a human friendly description of the filter (e.g. Country is Romania)

Interface mockups


The manual enrolment page allows teachers to specify the expiration date as the sum between an enrolment period and a reference starting date, which may be:

  • course start date
  • today - avaiable if the course start date was before today
  • course enrolment start date - available it is defined in the course configuration page
  • course enrolment end date - available it is defined in the course configuration page

If the enrolment period is Unlimited, then the starting date is ignored. Enrol01.png

In the Participants page, there are now two extend enrolment options.

  • Extend enrolment - is the classic version of extend enrolment page with some add-ons
  • Extend enrolment for all - is a new page designed to allow teachers to quickly extend the enrolment of many students.


The Extend enrolment page now allows user to increase/decrease the extend period for all user (inclusiv those with unlimited enrolment), regardless of the course default enrolment period. The new expiration date is the sum between an extended period and a reference starting date, which may be:

  • course start date
  • student enrolment start date - available if it was recorded (Moodle versions previous 1.9 did not record this information for unlimited enrolments)
  • student enrolment end date - available if it is not Unlimited
  • today - avaiable if the course start date was before today
  • course enrolment start date - available it is defined in the course configuration page
  • course enrolment end date - available it is defined in the course configuration page


Extend enrolment for all page works in a similar fashion, except that there is only one extended period choice and one starting date choice for the entire group (obviuosly, when needed - student enrolment start and end date, the computations are performed relative the user's data).


One way to attach notes to a user account is from the Participants page. There are three possible operations related to notes here:

  • Attach notes - attach different notes for each of the selected users (similar to the comment textarea used during assignments grading)
  • Attach note to all - attach same note to each of the selected users (similar to the Add /send messages option)
  • View notes (not showing in the mockup) - displays all the notes attached refering to the selected users

Below the course name, in the tab bar your may notice a new tab that links to the Notes page.


On the notes page, teachers can view private notes and notes shared by other teaches. Students can view protected notes (regarding them) and public notes (regardind other students).

Using the filter choices, the list of notes can be limited to only some notes. Using the order by choice (not shown in the mockup), users can order notes by author, students, last modified date, rating.


The image below presents the page for adding a new note for a single user. This page will open from the "Add a new note" link in the previous picture. It will also be used for quick note links: when the teacher clicks on a "Add note" link/icon next to a student's name, it will open with the student already selected.


Tasks and Timeline

  • April, 11 – May, 15 – collect opinions and suggestions from the Moodle community;
  • May, 15 – June, 30 – design and (partially) implement the specified features;
  • July, 1 – July, 21 – fix reported bugs, test usability under various browsers, and add requested features;
  • July, 22 – August, 19 – remove reported bugs
  • August, 20 – upload evaluation code to

See also

Back to: Student projects