Current problem

Problem is that we cannot just falsify log history by injecting log records from the restore file, events must be always triggered and we need to know where are the courses coming from, that means the restore process needs to log everything that is happening during restore.

• import (=== backup+restore) of activities should not try to restore any logs
• restore from different site cannot create log entries with non-existent users
• duplication of course (restore into new course) may bork stats
• statistics should probably ignore the events coming from restore completely

Possible solutions

A/ use events

1/ trigger \core\event\restore_started and \core\event\restore_finished events (this might be useful in any case)
2/ log writers would watch for these and start adding 'restore' origin when writing events to storage during the restore process

B/ new $PAGE->get_request_origin()

The idea is to have one method that tells you if you are doing something from normal page, ws, cli, restore. The restore code would use some private API to tell PAGE that restore starts/end or it could even use 1/, but that would require a new observer which does not seem optimal to me. At the same time we could add $PAGE->get_request_ip().

After A/ or B/ is implemented we could filter out logs coming from the restore process in stats and other areas where we want to ignore the events triggered during restore.

The next step would be to optionally restore the original log data - we would need backup/restore support in log stores and new method in base event class which would have to be overridden by events that can recalculate the ids.