Moodle Plugins directory: User Restore | Moodle.org
User Restore
Rogier van DongenThe 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.
Important note
Moodle removes ALL relevant data upon deleting a user account, and only the record in the user table itself remains. This utility can't do anything about this and is only capable of restoring the record from the user table.
Important note for moodle 2.7 and up
Before Moodle 2.7 there is NO way we can retrieve all information. However, with Moodle 2.7 and the new event logging tables, the original user information is stored in the event data. Therefore, from Moodle 2.7 onwards, this plugin will try and restore the original user information from there.
This effectively means, that from Moodle 2.7 onwards, we will have the correct original username, email, idnumber, picture and mnethostid. Before that, only the email could be restored, and even that method is not foolproof (due to the fact the username is cleaned with PARAM_USERNAME upon deletion).
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