PHPUnit via Composer in Moodle 2.4

Starting in Moodle 2.4 the recommended way to install PHPUnit for Moodle testing is via Composer dependency manager.

Benefits compared to old-style PEAR installations

  • much easier installation
  • local installation in Moodle dirroot
  • safe and easy upgrades

Installation in *nix

$ cd /your/moodle/dirroot
$ curl -s https://getcomposer.org/installer | php
$ php composer.phar install

Test execution in *nix

$ cd /your/moodle/dirroot
$ vendor/bin/phpunit

See http://docs.moodle.org/dev/PHPUnit for more information about testing of Moodle code with PHPUnit.

Replicating and fixing bugs

System administrators or users may find problems that developers can not reproduce or can not diagnose. I would like to describe my approach.

First step is to try to replicate the problem on the my own development machine which is usually very different from the original server. If I can replicate it then I can probably fix it and when it finally works for me it will probably work on the original server too.

If I can not reproduce it I usually try to get the same data (db dump, backups, etc.) and ask for the exact steps to reproduce it, preferably with screenshots. The full db dump is always the best way, unfortunately privacy regulations often prevent admins from sending it to me even in encrypted form.

The next step is to try to replicate the exact server environment – that is OS version, PHP, database, configurations, etc. If I can not replicate it on the same software then I might eventually give up and wait till somebody else manages to reproduce it or I have to keep reading the code until I find the bug.

If I manage to reproduce the problem on the same sw, but not on my own test server then the problem may be a PHP or database version specific bug or it may be outside of Moodle code. You would probably try to use different PHP and database version first, then search through respective release notes or bug trackers.

As you can see a lot of these diagnostics can be done easily by sysadmins that have access to the original data – of course they have to know a bit about PHP, SQL syntax and Moodle internals. The more time the reporter spends on a bug report the higher chance the bug gets fixed quickly.

In the next post I am planing to describe my typical security review, hopefully it will be a bit less boring,
ciao!

Consultation module

Half a year ago Andrea asked to review the old Dialogue module. I have found and reported several problems in it, unfortunately I did not like some design decisions and in the end decided to create a new module instead of fixing problems directly in Dialogue.

Consultation module is similar to Dialog but it is more targeted at teacher-student communication. Capability overrides allow it to work in student-student mode too.

Features and differences:

  • 1-1 communication contained in one course (forum is designed for more users)
  • included in course backup (messaging is not backed up)
  • optional limit of inquiries per student
  • notification block
  • recommended coding style (suitable example for new developers)
  • optionally teachers may review and interrupt communication of other users

The latest version may be downloaded from contrib CVS now or later as zip package. Please note it is compatible only with the latest 1.9.7 release or later.

Development of this module was funded by Italian Moodle partner MediaTouch 2000 Srl and Technical University of Liberec, Centre of Continuing Education.

Permissions continued

Today I have finished a new sample implementation of permission UI. Here is the screenshot ;-)

New permissions UI

New permissions UI

The (x) allows quick removing of permission or prohibits, the (+) leads to a form where you can select role to be given permission or marked as prohibited.

Is this easier to understand and use for ordinary teachers?

Permission evaluation revisited

Since 1.7 the evaluation of role overrides was a great source of confusion. I never understood it properly until I actually had to do some changes in the code. Some two weeks ago I started a sample implementation of new enrolment framework. When I got to function get_users_by_capability() I realised there is no way to improve performance of it. Also after spending a few hours studying the accesslib.php code and reading docs at How_permissions are calculated came to conclusion that we over engineered this, in fact I never saw anything like this anywhere else which is definitely not good sign.

How to solve this? Easy – steal ideas from known file system access control implementations :-D Each evaluation of access permissions is done for each group separately, you have access if you are member of at least one group that has access in given directory. It did not take long and I replaced the current complex permission evaluation code with new much simpler version that matches known filesystem concepts – yay!

You can find more information at Role overrides revisited and MDL-18475.

Install/upgrade related work

Last week was relative productive for me, finally I managed to start refactoring of installation and upgrade subsystem. I have cleaned up the code a bit, added some new features and removed parts that are not going to be used any more.

The installation and upgrade is now executed on one page only, this was needed for cli installer and unit test framework. This means we do not need upgrade autopilot and it is also a bit faster now. Another very visible change is that by default sql queries are not displayed any more, this was a bit of an experiment at first it turned out that there were several hidden error messages among the tons of sql. If you still want this feature you can add $CFG->upgradeshowsql = true; to your config.php. Some time ago I have reworked the upgrade locking, the sites are now inaccessible during upgrade – this should be much more reliable than the session based locking before.

Today I have added logging of changes done in server configuration, not everything is logged yet – only settings converted to new admin tree stored in config and config_plugins table are tracked. SImple UI is located at Report / Config changes.