If any of the access rules require the attempt to open in a new window, assume we
require javascript to attempt the quiz. This makes it harder to bypass the javascript
pseudo security restrictions.
The mtrace function is preferable for plain text logging/progress
output because it can be redirected if necessary. By convention it
is normally used in cron and can be used in CLI tasks if required.
This change makes the text_progress_trace class use mtrace instead
of echo and then flush. (Default behaviour of mtrace is to do
exactly that, but it can be redirected too.)
Before this change, if anybody is relying on mtrace behaviour to
redirect logs of cron output, this will fail for some parts of the
search cron output (and some other places like auth plugins).
Previously, when a during backup/restore the "Schema"-stage is loaded,
some settings are fixed if they are LOCKED_BY_HIERARCHY. However, user
data fields of activities can be locked, when the section they are
contained in has user data set to false. When this setting is changed on
the same screen, the fixed setting of the activity can not be "unfixed"
by javascript.
This patch adds a settings-level to the call of is_changeable. With this
only those dependency_settings are considered, which belong to parent
settings, which are not changeable on the current stage.
The function is_locked was changed to determine only, if the
dependency_setting want's the dependent setting to be locked.
In the previous version, is_locked did not only check, if the
dependency_setting want's the setting to be locked, but also if the
setting was already locked. A recursive call to the status of the
dependent setting leaded to problems, when unlocking locked settings.
Also the PHPDOC of the is_locked was adjusted to coincide with the current
usage in backup_ui_settings->is_changeable() and
base_setting->set_status(). In both functions all dependency_settings of
a setting are iterated to check if this setting should be or is LOCKED_BY_HIERARCHY.
The actual state of the setting was therefore either checked beforehand
or is not interesting, since the question is, if it shall be changed.
This new test defines different combinations of global and local user
data settings during the restore process and tests that global defaults
can be overriden.
All external functions must check all capabilities before returning data.
The calendar API itself does not check capabilities (I wish it did), so we must be
careful exposing these functions to webservices.
