Creating the Necessary User Classes

Having now created a theme for the environment, it was next necessary to review the default types of user available within the system and modify them to meet the requirements of the school as specified in previous chapter.

By default Moodle offers four types of user class, Admin, Creator, Teacher and Student. The default Admin user class within Moodle, has overall control of all aspects of the system and can do anything and go anywhere within the system, which fits very well with the requirements for the Administrator user class. The default Creator and Teacher user classes are practically identical with the only difference being that a Creator has the ability to create new courses within the environment. As within the LPS Moodle environment, only Administrators should be able to create new courses, the default Teacher class was used to represent Teachers in the environment with the option to allow editing switched on. This option would allow teachers to edit courses that they were assigned to. The final user class offered as default by Moodle is Student, this class of user encapsulated all the desired functionality required for a LPS Moodle Student user.

Although the functionality required for the three LPS Moodle user classes was available via the default Admin, Teacher and Student user classes, it was necessary to modify the Teacher and Student classes to remove the ability for members of these groups to alter their passwords. To do this it was necessary to locate all the possible ways in which passwords could currently be changed and modify the Moodle source code to prevent the option from being presented to the user if they are not an Administrator.

It was found through thorough investigation that there were three places within the current system where a user could change their password. These were;

• On the homepage, the user was given the option to click a button if they have forgotten their password. Clicking this button sends and e-mail to the specified user with a link to the change password function.
• If the user chose to view their own profile, they were presented with a button that allowed them to change their password.
• If the user chose to maintain their profile, they were given the option to change their password.

Through reading the technical forums at http://moodle.org, it was found that many other people had the same desire to prevent the changing of passwords. There was however mention elsewhere on the forums of a method within Moodle called isAdmin. This method would return a specific value if the current user was an Admin. By wrapping the parts of the Moodle source code responsible for displaying the button on the homepage, the button on the view profile page and the new password field on the edit profile page, within a simple IF statement with the condition that the current user was an Admin (found via the use of isAdmin), it was possible to only display the buttons and fields required to change passwords to Administrators, thus removing the ability for Teachers and Students to change their passwords. The method for doing this was then reported back to the Moodle community via the technical forums.

Problems found during Demonstration

To demonstrate the functionality implemented during stage 1, a simple fictitious course was created to demonstrate that the required functionality for the user classes was present. Although the demonstration went very well and the required functionality was found to be present, it was also noted that the level of detail within the individual profiles needed to be changed. Firstly the ability to change certain fields in the users profile should be limited to Administrator such as Name and Email Address. Secondly certain fields would only confuse the user and should be removed completely such as Digest Type.

To achieve this new functionality it was necessary to drastically alter the Moodle source code file responsible for displaying the user profile editing form. The profile display and edit file (edit.html) was modified, again using the isAdmin function. Within the file, the source code responsible for displaying each of the elements deemed unnecessary was again wrapping inside an IF statement with the isAdmin clause, however as this file was a HTML file it was necessary to embed the new PHP code within the HTML form object. Also the form processing file (edit.php) requires that certain fields are passed to it from the form. As several of these fields had now been removed, it was necessary to hard code hidden fields into the form that would pass on the current data held within the user profile and avoid errors relating to missing fields.

The following images show the difference between the profile editing screen displayed to Administrators and the screen displayed to Teachers and Students.

Student / Teacher profile edit screen

Administrator profile edit screen.