This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
* calendar_get_link_previous() and calendar_get_link_next() are no
longer used anywhere except from the already deprecated
calendar_top_controls() so we should deprecate these as well.
In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
This removes the three-month pseudo block from along the side of the
main calendar, and deprecates relevant files/methods which will no
longer be in use.
- Create new web services for manage subscription (Update calendar subscription)
- Modified delete subscription feature to use Web service.
- Midified update subscription feature to use in-place editbale
- Delete subscription feature now have a confirmation box before processing.
- Fixed some accessibility issues
- Used 'Delete' instead of 'Remove' for deleting subscriptions
Now that subscriptions and exports are accessed from the same page which
is linked as "Import / export calendars", there is no need to have a
separate "Export calendar" link.
* Store the view mode of the calendar in the calendar_information
object.
* Let the month exporter handle the production of context data by
moving 'viewingmonth', 'showviewselector', and 'viewinginblock'
inside it.
* Set the proper calendar view mode in the core_calendar/month_detailed
template.
* Pass the calendar view mode to the
core_calendar_get_calendar_monthly_view WS function.
When calling the calendar_get_allowed_event_types function with
no course id, it is supposed to return true if you have the
relevant permissions in any course.
For users who have the managegroupentries permission, this was not
the case - even though it works correctly if you call the function
with a supplied course id.
This change makes behaviour with and without a supplied course id
consistent.
Eloy Lafuente (stronk7)