Revert the change I made in MDL-59382 to correctly set the id for inline
form elements because it's breaking a bunch of different places that had
already worked around the problem.
For historical reasons repositories need to call add_file_to_pool
to sync file records. However now that a before_file_created hook
has been added additional information is needed by add_file_to_pool.
Ideally add_file_to_pool and friends will become private/protected,
so we need to remove all uses of it in core.
This patch adds some new methods to the file class to allow syncing
to be managed internally by the file and the file_storage class.
Now we only predict using the most recent range available, this means
that if someone upgrades to moodle 3.4 at three quarters of a course
we will only calculate the latest range, previous ranges were not
displayed anyway once more recent predictions were available.
This commit deletes all previous predictions :) this shouldn't be a
problem in master as we don't provide any guarantee, the alternative
(retrive sampleids from mdl_files) would have been slow and a waste of
time as well as require horrible code in an upgrade step (text fields
do not accept defaults nor we can use NOTNULL).
The unit test was creating four events, and then relying on them being
retrieved in the order in which they were created.
I've modified the test to:
* ensure timecreated are spaced apart; and
* add an order by timecreated when fetching them.
These tests are an abuse and should not have been accepted. Behat tests should use real pages.
Adding testing only entry points to Moodle is a bad security practice and is not the purpose of behat.
* Add student1 and student2 login/logout steps for the course
participants filtering scenario in order to have last access data
for students 1 and 2 since the participants table is sorted by last
access by default.
* Remove @javascript tags for the following scenario:
- Filter users on assignment submission page
- Filter users on view gradebook page
- Filter users on course participants page
JS is not really necessary in these scenario and we can get faster
execution time.
This is useful because config_logs are sent via logstores, and we may be interested to know how
many people change a particular admin setting across many sites (aggregated data).
