Feature: Only rollback failed changes

[jrchamp]

The current approach of "one transaction for all changes" seems like it doesn't allow people to make partial progress on updating things. When a single problem occurs, all changes are rolled back.

If a transaction was started for each batch of changes, this would allow for successful changes to be applied and for useful error messages to be included in the Dates report alongside the change that failed. Specifically, plugins which throw a moodle_exception when an issue occurs could be caught at the instance level and not prevent other changes from being processed.

[timhunt]

"When a single problem occurs, all changes are rolled back." to me, this is a feature not a bug.

But, the UI should not suck when an error occurs, and from what you say, it seems that it does. But, I would fix the UI, not the transaction use.

[jrchamp]

Hi @timhunt ! Thank you for your speedy reply. I agree that using transactions to avoid an inconsistent state is exactly the feature that transactions are designed to provide.

From a progressive enhancement viewpoint, using a transaction is a great step forward that has already been made. I'm proposing dividing the single transaction into multiple separate transactions, taking the next step in leveraging the feature. Each logical section of the report's UI can have its own transaction and thus, transaction result. This allows instructors to avoid losing effort invested in updating dates for sections that do not error, while highlighting sections that did error. As this report is designed to make it easier to update many items at once, an error in a single plugin or activity should not prevent this report from providing its core value.