1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
This combines the following changes:
* Event for group member added
* Event for group member removed
* Event for group created
* Event for grouping created
* Event for group updated
* Event for grouping updated
* Event for group deleted
* Event for grouping deleted
* Adding tests for deleting functions
* Bulk remove of members uses low-level API
The reason for this is that a bulk event has no value from a logging
perspective as it is not granular. So now, the API is a bit slower,
but the information the events contain makes sense, beside this is
not (and should not be) used very often.
The reason why the events_trigger_legacy() is kept is because we
cannot create a new event for this, as we don't encourage developers
to created bulk events, for the reasons mentioned above.
I removed the call that gets the user record from the function
groups_remove_member() as it was not required and only appeared
to check if the user existed. It appears to be safe not to do
this check as nothing would fail down the line.
* Bulk unassign of groupings uses low-level API
As the previous commit, we keep the legacy event for now as it would
be wrong to create a new event to replace it.
Also, the code has been changed to call the low-level API to unassign
groups from groupins, even though at the moment there are no
events for that function.
* Bulk deletion of groups uses low-level API
Again, we keep the legacy event because replacing it would force
us to create a new event that does not make sense. See MDL-41312.
* Bulk deleting of groupings uses low-level API
* Asserting legacy event name in unit tests
* Minor SQL query and code improvements
List of fixes:
* Add a simulated drag start event to fix problems with block drag and drop that
were expecting it.
* Add an access-hidden title for the General section in a course format. This
is used to provide the text for the drop region (better than the first activity in the section)
* Changed the text in the list to 'Move to "General"' instead of 'Move after General'. This
makes more sense for activities when you have a list of activities and sections together.
* Added more PHP Documentation
* Localised strings for get_name()
* get_legacy_eventname() is now static
* get_legacy_eventdata() is now protected
* Testing legacy event data
* Added missing defined('MOODLE_INTERNAL') checks
* Added missing call to add_record_snapshot()
Includes:
* no more hacky reloads, everything is written only once and kept until cache reset
* lang menu list is now cached in MUC
* both string and lang menu caches are compatible with local caches on cluster nodes
* config-dist.php cleanup
