There is at least one LDAP server (Sun Directory Server) that doesn't
support Paged Results extension, even if it supports LDAP version 3. So
checking just for LDAP version is not enough.
If possible, we check the supportedControl attribute of the LDAP rootDSE
and see if the paged results control is available. This needs an LDAP
connection, which might not be possible to establish before we configure
some essential LDAP settings (server, bind user, password, etc.). Thus
we try to establish the connection and check the supportedControl
attribute. But if we fail, we perform only basic checks that are less
accurate and err on the side of cautiousness.
This was is pre-loading some modules which are not used in boost:
* Block docking
* Popup Help
The other pre-loaded requirements were used for YUI dialogues and
modals. With time we are moving away from these, so rather than
'pre-loading' we can let the yui loader do its job.
This unit test is not really verifying that internally igbinary
in being used but just igbinary availability and, by double
serializing, that it works for a semi-complex object.
The test will be skipped if igbinary is not available.
On Exiting scrom activity, it goes back to course
and scrolls to section. On slow machines next step
fails. To avoid such case navigate to home screen
and then follow next step.
In the recent issue MDL-56225, we started to record the current user as
the usermodified in the forum_discussions table when updating a forum
post. It made sense but it was a mistake.
Even if the current user really modifies the discussion by updating the
post, the field usermodified has actually been always interpreted and
displayed as the last post' author. Not as the last user who touched the
discussion.
This patch reverts that particular change to the previous behaviour and
adds explicit unit test for it.
This fix modifies styling for pages having no navbar, such as the
dashboard, site home and default dashboard pages and fixes an overlap
problem with the buttons and context header.
1) Some previous deprecations are removed to reduce the amount of
code sent to the client
2) Other very-old functions are also sent to final deprecation
This is more agressive than our standard deprecation process, but with
the nature of this old js it seems the best way forward to reduce the
amount of obsolete js sent to clients.
