We have moved to GitHub Issues
You are viewing the read-only archive of Umbraco's issue tracker. To create new issues, please head over to GitHub Issues.
Make sure to read the blog posts announcing the move for more information.
Created by Stephen Rogers 21 Aug 2018, 11:26:04 Updated by Sebastiaan Janssen 05 Sep 2018, 14:57:27
Relates to: U4-10502
As part of the recent release for U4-10502 a Delete User button was added with the logic
ng-if="!model.user.lastLoginDate"
presumably under the assumption that if you've never logged in you can't have done anything so deleting is safe.
Unfortunately it seems that if you upgrade an existing site from a version < 7.7 to a version > 7.7 (from 7.2.8 to 7.12 in our case) the lastLoginDate fields are wiped (I guess because of changes to user / user group structure)
After migration all the users show as "never logged in" and are deleteable even if they've a history of publishing pages.
A keen user has deleted some legacy users and now content is inaccessible in the back end.
The logic for whether to show the Delete User button needs to be cleverer than !model.user.lastLoginDate, or there needs to be a check on history before users are deleted.
Ouch! Sorry to hear that, I really hope you have a database backup! 🙈
Definitely a big problem, we'll look into it!
We did, but in the end it was easier to update the various tables that referenced user ids to a user id that still existed (umbracoLog, cmsDocument and umbracoNode I think)
After some discussion, this is how we want a fix for this to be implemented:
In 7.13 we'll run a migration that does a query for each user without a LastLoginDate:
SELECT documentUser FROM cmsDocument WHERE documentUser = 3 UNION SELECT parentUserId FROM cmsTask WHERE parentUserId = 3 UNION SELECT userId FROM cmsTask WHERE userId = 3 UNION SELECT userId FROM umbracoLog WHERE userId = 3 UNION SELECT nodeUser FROM umbracoNode WHERE nodeUser = 3 UNION SELECT userId FROM umbracoUser2NodeNotify WHERE userId = 3
Of course the identifier will change per user. If no results are found, we don't run the risk of errors like you got in this case. If there is a result we set the LastLoginDate to DateTime.Min to indicate: we don't know when they last logged in but they have definitely been active before.
FYI: we're almost done completing the move to the new issue tracker as announced here: https://umbraco.com/blog/a-new-take-on-the-umbraco-issue-tracker/
I am closing the issue here on the old issue tracker, but it will continue on the new issue tracker. The new link is: https://github.com/umbraco/Umbraco-CMS/issues/2920
Priority: Normal
Type: Bug
State: Closed
Assignee:
Difficulty: Normal
Category:
Backwards Compatible: True
Fix Submitted:
Affected versions: 7.12.1
Due in version:
Sprint:
Story Points:
Cycle: