Entity has been using Moodle for several years. Site has been marched through versions beginning 1.9.highest all the way to 3.3.highest (currently).
In mdl_user table, accounts set to either manual or email that have 'expired' have been obscured ... username becomes their email addrress + the epoch time stampt of the date that account went 'dormant'. Those accounts original username gone.
Entity is now working towards what they call 'sso' but for many of the users in the moodle it will really be nothing more than a method of authenticating ... SiteMinder is being used on the backend. Still, they want all student accounts touse what they are using ... saml2.
In the past, with K12 entities that had been using 'manual' and moving all student accounts to 'ldap', one could change all accounts via csv without much of an issue.
This entity, however, is corporate and have never used ldap - moodle servers are hosted in cloud.
Attempting to update accounts now via csv is picking up on the username field's
email address and saying there is a duplicate. But there really isn't. The email field looks like:
cbd44f8b5b48a51f7dab98abcdf45d4e (as an example) and I'm not sure what that is.
The Moodle Admins of the site have never restored any account.
Now the question ...
IF I remove all rows in mdl_user whoee email field contrains a '.1' in it (the epoch time stamp on dormant accounts), what other data might be retained that basically becomes orphaned?
Anyone know?
'spirit of sharing', Ken
Well, this appears to be yet another short blog in a forum .. I'll answer my own question ...
Can do ... with no seen/discovered ill affects.
In light of GDPR wonder why Moodle keeps such accounts (never delete) even if Admin level users can't see them in any interface of the Admin UI. Even before GDPR, since the accounts didn't appear to have any activity on the site still tied to them, and no way I can re-call for Admins to 'un-obscure' the accounts, why were they even there?
Just thinking out loud of course ... ;)
'spirit of sharing', Ken
Re: Any adverse affects to removing 'dormant' accounts?
Your research is much appreciated. The argument for the "dormant" was that, one can revive them in case they come back, without losing the contact to their work - which I understand. But to my knowledge there is no web interface to revive such users other than you get errors if you try to create an identical user again. Must admit, that I haven't tried recently.
So a safe strategy would be to first delete the user through Moodle, if no reaction after a certain time period, delete the corr. row in the database(?)
Re: Any adverse affects to removing 'dormant' accounts?
Thanks for response. Probably should have included what was observed and led to the question ... site moving all users to another authentication via CSV - Moodle 3.3.x. This is being tested first on a clone of production site. Must keep users whose accounts are active on production server ... they have some courses that never end.
Using a correctly formatted csv file (checked and double checked) for just one test user, would get a notice in review that a duplicate address existed. Uhhh ... nope, not in an active user row - only place found was in the obscured column.
Site uses very few mods/activities ... but one important one is certificates. Searched certificate tables for the test user id ... none found. Did same for files. Did same on other tables for other mod/activities/participation ... whatever I could think of ... including logs tables. Couldn't find anything.
So knowing that I don't know everything there is about a moodle and DB for it, thought I'd ask if there was any un-discovered catch 22.
Anyhoo ... on down the road now! ;)
'spirit of sharing', Ken
Re: Any adverse affects to removing 'dormant' accounts?
> Using a correctly formatted csv file (checked and double checked) for just one test user, would get a notice in review that a duplicate address existed.
So it is still the same. Username and e-mail must be the unique fields.
Re: Any adverse affects to removing 'dormant' accounts?
True ... those two fields must be unique ... but ...
the email column had something like 'sdefoihergkewdpakjgwoeqwrhkds' in it - which translates to what/where?
The username now had 'formeraddress@domain.+an_epoch_time_stamp_of_when_account_reset'
example: ktask@sonenet.net.1412398132942
The message was 'Duplicate address found' ... huh? That reads to me to be the email column ... not the username column ... but hey, maybe I don't speak the same English! :\
Like I said ... removal of the 'junk' doesn't appear to have had any ill effects, so that's ok by me.
The site, BTW, has been marched through Moodle 1.9.x to 3.3.oneshortofhighest now ... and I have seen old stuff in DB tables before that never got cleaned up ... just hangin' round doing nothing for not any purpose I could determine. Uninstalls didn't appear to clean up tables.
Oh, well ... all is well that ends well, right? ;)
'spirit of sharing', Ken