What Counts As "Modified" for Automatic Backups?

Re: What Counts As "Modified" for Automatic Backups?

by Natassia Stelmaszek -
Number of replies: 3

Still hoping for an answer.

Reducing the number of copies is one option.  In the past we've had some rather bizarre requests from professors like, "I need a copy of the course the way that it was at the start of the month."  We could accommodate those requests while the number of backups was low and now the faculty seem to expect that we'll always have that ability.  I'd like to find out if legitimate course changes are being made or if someone is doing something silly that is causing me headaches.

I can conceive a situation where a large number of changes might be needed but not to 94 (now 98) being modified on at least a weekly basis.  I'm concerned that there might be some automated process, course configuration, etc.,  that is triggering the "Modified" status.

Natassia

Average of ratings: -
In reply to Natassia Stelmaszek

Re: What Counts As "Modified" for Automatic Backups?

by Rebecca Trynes -

I have found something very similar happened in my upgraded instance of Moodle. I went from 3.1.5 to 3.3.2 and now a bunch of courses from 2 years ago are getting backed up due to a calendar event being added on an assignment that hasn't seen activity since 2015!

These calendar events were added just yesterday via the course report log.

Was there some code added to Moodle core that would have caused this new event to pop up in old courses? Maybe a new database column in the event table??? Or simply a new event for assignments that automatically add an event to the calendar? i might have to look back through the change log to see if I can work it out.

More importantly: when will it stop!

If anyone knows anything, I'd love to hear it.

Average of ratings: -
In reply to Rebecca Trynes

Re: What Counts As "Modified" for Automatic Backups?

by Rebecca Trynes -

I suppose it could have something to do with any of the following updates that occurred in assignments?


=== 3.3.2 ===
* assign_refresh_events() Now takes two additional parameters to refine the update to a specific instance. This function
now optionally takes the module instance object or ID, and the course module object or ID. Please try to send the full
objects instead of the ids to save DB calls.
=== 3.3 ===
* All pluginfile file serving functions now pass through the options to send_stored_file() (all assignment plugins should do
the same).
* Fixed calendar event types for overridden due dates from 'close' to 'due'.
* Removed calendar event type of 'open', since mod_assign only has the 'due' event type. No point in creating an override event
for an event type that does not exist.
=== 3.2 ===
* External function mod_assign_external::get_assignments now returns additional optional fields:
- preventsubmissionnotingroup: Prevent submission not in group.
- submissionstatement and submissionstatementformat: When there is a submission statement defined.
* Proper checking for empty submissions
* Submission modification time checking - this will help students working in groups not clobber each others'
submissions
* External functions that were returning file information now return the following file fields:
filename, filepath, mimetype, filesize, timemodified and fileurl.
Those fields are now marked as VALUE_OPTIONAL for backwards compatibility.
Please, note that previously the filename was part of the filepath field, now they are separated.
* Submission and feedback plugins can now specify file areas related to their configuration data,
which will then be included in backup and restore; see assign_plugin::get_config_file_areas().
* Submission and feedback plugins must now return the specific list of configs available for external functions,
this can be done implementing the new assign plugin method get_config_for_external()
* Webservice function mod_assign_get_submissions returns a new field 'gradingstatus' from each submission.
Average of ratings: -