Regressions caused by bad refactoring in commit 21feac3bea.
Test cases in tests/CommandInterpreterTest.php were made against the pre-refactoring code, and now check out with the fixed code.
Failures were caused by not changing logic structure when moving from multiple exit points (each if point would return directly with a null or an object) to setting a result variable and then falling through to a common exit point. Without the if statements being restructured, the result variable would just get overridden by the next case.
I've extended the rights framework (centering on the Right class and Profile::hasRight()) to cover
Web login and API use. This will make it possible to prevent login and API use by users.
I added two new Right constants to the Right class: WEBLOGIN and API. I check these rights using
Profile::hasRight() when initializing users. If the rights check fails, I throw an exception.
I created a new AuthorizationException class for this particular
exception, in order to allow a different UI for these kinds of exceptions (or whatever).
* 0.9.x:
* update translator documentation. * remove superfluous whitespace. * tab to spaces. * add FIXME for undocumented class.
* update translator documentation. * remove superfluous whitespace. * L10n updates. * small refactoring in publicrss.php. * remove PHP4-isms
Localisation updates from http://translatewiki.net.
Double quotes to single quotes.
* improve L10n consistency for English. For example proper punctuation for all button and label titles. * fix some i18n bugs (in-message variables). * update/add translator documentation. * remove superfluous whitespace.
add path separators for Plugin::path()
argument to send email summary to all users on all sites
fix indentation in siteemailsummaryhandler
fix indentation in sendemailsummary.php
fix indentation in Email_summary_status.php
fix indentation in EmailSummaryPlugin.php
fix indentation in usermailsummaryhandler.php
Workaround for deleted profiles still appearing in cached subscriptions/subscribers lists: if we couldn't fetch them, don't include them in the ArrayWrapper.
ArrayWrapper doesn't deal well with null entries, which aren't meant to happen in how it works. This code has recently changed from dying directly with a PHP fatal error in that case to throwing an exception, which allows tracking down the caller.
It looks like there might be some cases where profiles and their matching subscriptions get deleted, but the subscription entries don't get properly cleared from cache... that still bears further investigation. The regular code path looks ok; calls Subscription::cancel() from code called in Profile::delete(); but if they're batch-deleted instead of one row at a time, that could fail to trigger.
