Moodle Plugins directory: User Restore | Moodle.org
User Restore
Rogier van DongenSEBSOFT USERRESTORE PLUGIN
The Sebsoft User Restore Plugin offers you the possibility to restore user accounts that were deleted from moodle.
When the plugin has been installed, you can select a number of user accounts to restore and optionally send an email informing them their accounts have been restored.
This plugin takes the following into account:
- Users to be restored are checked on e-mail: if an e-mail address already exists for an active account, this user will not be restored.
- Users to be restored are checked on username: if an username already exists for an active account, this user will not be restored.
- Users to be restored are checked on MNET host: if the MNET host of the account to be restored is not the locally configured one, this user will not be restored.
Version 4.0.0
Version 4 onwards brings a new strategy. Where version 3 used a cache which was extracted from the logstore, version 4 uses it's own table to store restorable user data. The main (and really, only) reason for this change is that the logstore is incredibly slow on MariaDB/MySQL when the dataset is "large". Version 4 therefore hooks into the user_deleted events to store restorable data. Version 4 also fetches it's initial data from the logstore (using a background task). All data can still be reset. The aforementioned background task will then perform a full run again, determining all restorable data again (of course the amount of restorable data depends on cleaning settings of the logstore. Once the logstore is cleaned, we no longer have this data available).
Important note
Moodle removes "ALL" relevant data upon deleting a user account, and only the record in the user table itself remains (or so it should be). This utility can't do anything about this and is only capable of restoring the record from the user table.
Having said this, this is really not entirely true. Plugins are supposed to either hook into the user_deleted event (older code) or implement a "pre_user_delete()" hook. Even Moodle itself does not clean all user data upon removal (this is especially true for activity modules). Multiple forum threads and issues exist, but more information can be found e.g.:
Beneficial feature
Taking the above into account, this tool also happens to have the added feature of being able to undelete a user and investigate the information that was never deleted upon user deletion (using the privacy API). Please be aware that actual implementation of the privacy API is required to be implemented by plugins to be able to see the remaining user data. If a plugin does not (correctly or fully) implement the privacy API, it's not visible from the Moodle interface that a specific scope may still contain user data.
INSTALLATION
- Copy the userrestore folder to your admin/tool directory.
- Configure your admin tool.
- We're ready to run!
Useful links
Screenshots
Contributors
Cheers, Rogier
Can you please provide an up to date source control url for Moodle 3.10 ?
Checked up to Moodle 3.10.
Note the following changes:
- Decoding the event data now takes the JSON format setting of the logstore into account (decoding should hence be transparent no matter what serialisation method is used).
- user_deleted handler now no longer works by default. It must be enabled to work (reason: see Gemma's comment; bulk deletion is severely impacted)
- Cache refill can now be done 10 records at the time (apart from the full refill and smart refill that already existed).
- Added notification indicating the number of missing cache records.
Source control URL has been fixed (sorry for the massive delays; this year has been messy and chaotic indeed).
Cheers!
Rogier
Please, help me, I have about 30,000 accounts, 1464 of them have been deleted. The plugin is installed 3.6.1 (LTS Moodle 3.5), just a week ago the plugin worked and restored users. Now he says fill the cache. I tried to append and full refill the cache, tried it the same way through CLI (--execute = tool_userrestore \ task \ filldeletedcache) I waited for a couple of hours, reinstalled the plugin .... it did not help. I see that the task is starting, but it does nothing, there is no load on the CPU. What else to try?
Dave
Every now and then I think about tackling this in a different way, but one of the major challenges is that we cannot resolve things without severe impact on processing time.
The reasons for this are plenty: the log tables in Moodle, especially on MySQL, are notoriously slow due to the huge amount of records.
This makes JOIN-ing virtually impossible, hence the reason to try and implement some form of caching. However, filling the cache is also tediously slow when there are a substantial amount of users that were marked as deleted.
We might even end up doing a complete rewrite, implementing a range of ways to use this tool. For our original use cases the tool works flawlessly, but again: when there are 100's or even 100's of deleted users I agree with the process becoming rather unusable. I hope to be able to follow up on this some time soon, but it could take a while.
Cheers, Rogier
thanks in advance
That depends on what causes the error. Without information as to why this error occured (you might want to enable full on screen debugging) it could have come from anywhere.
Having said that; i think this error might be caused by the database layer itself.
I would advise you to either add a so called "debuguser" to the Moodle config; temporarily enble full debugging mode ("show all errors" and "enable display" so you can see it in your browser).
I would not be surprised if ultimately the message shown to you would be "MySQL has gone away"; which would be an indication the database server dropped/closed the connection.
In that case; there's nothing I can do in code (something I already suspect because the process does run but ultimately fails).
By the way: 67 users isn't that much. What may be more interesting to know because it highly influences the length of the "refill cache" process. How many deleted users does your target systeem have in total?
Thanks for your answer in advance,
Cheers
It is as you said it gives 2 error messages "MySQL server has gone away".
Its really bad we cannot do anything, i really needed those users back...
My target system only have 67 deleted users
Thanks for reply,
Cheers
The only thing I can safely advise you for now is to have your systems administrator increase the timeout for MySQL.
All cases we've seen with this specific type of error were resolved when the database management system is allowed to run longer.
I've been wanting to update the process again so it's less prone to crashing due to the database dropping the connection/stopping the query but unfortunately lack the time to do so.
Because the process dives deep into Moodle's event logs; I'm suspecting your log table might be on the large side (maybe gigantic). The whole issue is within this table and the fact MySQL does not have the best optimisation. Large tables, such as the event logs, therefore might be the cause for long running queries that in turn cause timeouts.
I'm hoping I can generate some time soon to tackle this less than usable process of filling usercache and add some drop-in "instant query" methods to match userdat based on a selected user, but this also _might_ not be the best approach if any of the search variables for users are deleted through the Moodle user deletion process. In other words: a decent fix may lead to being less able to _search_ in relevant data.
Cheers
Having been familiar with the caching timeouts, see the updated description above. A new strategy has been implemented.
Please be aware the initial datafecthing can still take a _significant_ amont of time, especially when the logstore is huge and/or there are many, _many_ deleted users.
After the initial data fetch, the scheduled task _will_ be disabled (it is resettable though) and all the work will be taken over by hooking into the user_deleted event.
This new strategy makes a lot more sense even when the plugin stores the relevant data itself now.
Cheers