While restoring course/activity, restore will blindly insert grade_item
sortorder. Which cause dulicate sortorder and lead to unpredicatble sorting
results.
Now we will call grade_item::fix_duplicate_sortorder() after restore is finished
to fix duplicate sortorder and order grade items to the closest order possible
Note we can only fix certain generic links, we can't handle ones like
/grade/report/{reportname}/index.php, but fortunately, we were only
using the generic ones.
I added a couple of other likely things too (badges and participants
list).
This commit contains three changes in the three files:
1. A bug in the backup process meant that anything logged after a
certain point did not appear in the on-screen display of the
backup log, because the logger was serialised and deserialised
but display code referred to the old version. Changed so that
code retrieves new object.
2. Add more information to backup log when there is a missing file.
3. Add more information to restore log when there is a missing file
(and remove existing code duplication of the current message).
The 'missing file' situation is one that generally shouldn't occur in
normal usage, but when it does happen, it is useful to have full
information about the file.
Previously, restore was blindly inserting the old sort order into the
database, causing duplicate sortorders which lead to unpredicatble
sorting results.
Now we will use the api function to add it after the original sortorder,
this means if a duplicate exists in the original location, this item
will appear after it.
* When looking for texts inside the page or inside
other containers we should wait until the elements
are visible.
* Same when expanding tree nodes.
* Normalizing loops to spin() function using
behat_base::TIMEOUT and behat_base::EXTENDED_TIMEOUT,
leaving TIMEOUT for DOM load processes and
EXTENDED_TIMEOUT for long processes that involves JS
too.
* Add page load waits between actions that involves
reloading the page.
In general aiming for compatibility with multiple browsers,
firefox, chrome and phantomjs to be more specific.
* Removing hardcoded waits
* Adding @_alert, @_switch_window and @_switch_frame tags,
to label actions that different drivers have problems with.
* Adding missing @_files_upload and @_only_local tags to features that
uploads files.
* Fixing a few wait for page ready what specified miliseconds.
* New methods to ensure elements (usual selectors), sections and editors
are ready to interact with
* Changing the select an option implementation to deal with the different
drivers implementations when listening to JS events.
The restore progress bars introduced a bug when restoring Moodle 1.9 backups.
build_plan needs to be surrounded with start_progress/end_progress with the mode
set to indeterminite or it throws coding errors.
Files bigger than 4GB is not supported at this point. Zip archiver doesn't know about it and always returns true. We need to verify if it is a valid file or not and delete if not
Also delete the backup file immediately if anything goes wrong anywhere in backup. We don't want to use up space
Dan Poltawski