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
This commit moves user agent related functionality out of several
core libraries and combines it into a more manageable class.
All core uses are converted and functions deprecated in favor
of the new class.
This commit moves user agent related functionality out of several
core libraries and combines it into a more manageable class.
All core uses are converted and functions deprecated in favor
of the new class.
* 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()
