This is a result of a pretty intensive effort to make the form less
sucky, given the completion strings mess around. It partially solves
MDL-39419 too as it clarifies the course completion link in the course
administration block.
I must admit and record here that I'm pretty desperate by the current
state of the core_completion and how strings from it are inconsistently
used at various places with different meanings. For example the 'Completion
tracking' may mean the mode of how activities are tracked within the
course as well as the overall feature of course and activities tracking.
While a same phrase can be used in English for both this meanings, not
all languages have such luck and translating it is a pain in the ass.
Finally, let me give the credit for wording and UI design suggestions to
Helen Foster and all others who helped with this. This has been one of
the most ugliest forms in Moodle and we believe we made it better
(although we know it's far from perfect).
This patch does not alter the code, only some syntax fixes and
coding guidelines rules are applied. Strings are re-ordered
alphabetically with no change of their wording. PHP doc blocks
reconstructed using the Git log records.
Issues:
1. Fix setType calls
2. Changing from default to all and editing again, default is still selected.
3. Uncheck all options causes error.
4. Doesn't seem to be restricting based upon option.
5. Picked all and got coding error with the database thing.
6. Bad title: https://github.com/samhemelryk/moodle/commit/wip-MDL-37500-m25#L1R157
7. Amend comments - should only be removed once 2.5 is the minimum version for an upgrade.
8. Document the defaultsharing option.
Outcomes:
1. Fixed - copy paste error.
2. Fixed - mforms was applying the default value despite a value being provided. A quirk of elements with array names.
3. Fixed - validation now requires at least one option to be selected.
4. Fixed - issue rose from definitions not being re-parsed. cache/admin.php now reparses the first time a user visits the page.
5. Fixed - better purging of definitions when working with them anonymously. Unit test added.
6. Fixed - new string added and used.
7. Fixed - comments amended.
New issue to address parsing of definitions during upgrade.
New issue to add debugging notice if definition sets only one possible sharing option and that option is user input.
Bug: There was no way to create an instance of a lock plugin for use
within Moodle.
Solution: Implemented management interfaces as part of cache/admin.php
to allow for instances to be added and deleted.
This was done in along the same lines of adding store instances.
This patch includes refreshing of borked files in file pool and basic prevention of race conditions. It also helps with diagnosing of file pool permission problems, detects coding errors and some other type of problems including sha1 collision jackpot.
Not all add-ons require administrator's attention during the upgrade
now. They are now listed only if there is an update available for them.
Also, it's not true any more that add-ons must be updated manually. They
can be updated using the automatic deployment feature, too.
This change is a large change to the way sessions are handled
within MUC after it was discovered that session did not function
as expected when any store other than the default session store
was being used.
As part of this change the session loader has been largely
customised in order to consolidate session data for the loader.
The unit tests have also being greatly increased to provide
better coverage for sessions.
- 'List of courses' is split into 'List of courses' (available) and 'Enrolled courses', CFG->disablemycourses is deprecated;
- CFG->frontpageloggedin by default shows list of available courses;
- There is separate item to display course search box
- CFG->maxcoursesincombo is deprecated
- CFG->maxcategorydepth changed default value to 2 since we have AJAX loading now
- FRONTPAGECOURSELIMIT is transformed to CFG->frontpagecourselimit
c
moodle/blog:associatemodule and moodle/blog:associatecourse should not be used
anymore as per the discussion in the issue. Everyone is free to blog about anything
they want to blog about.
Plugins may use this general tool for uninstallation and eventually
removal of the deployed source code. At the moment, this is implemented
as a wrapper for the core function uninstall_plugin() with an extra hook
in the relevant plugin info subclass.
For non-standard add-ons, the tool can remove the deployed plugin source
code as well, if the web server has required write permissions. Ideally,
all add-ons installed via the new tool_installaddon should be removable
via the web interface as well.
