migration for inactive user purge #6676
Conversation
|
@smithellis Forgot to mention one more thing. Just FYI, you can use |
|
|
||
| cutoff_date = timezone.now() - timedelta(days=3*365) | ||
|
|
||
| query = User.objects.filter(last_login__lt=cutoff_date).annotate(has_content=has_content_criteria) |
There was a problem hiding this comment.
Why are you using annotate here instead of filter/exclude/Exists?
There was a problem hiding this comment.
This use case absolutely works - I think it's just not specifically called out in the 4.2 docs but is in later docs. I can run this query and see the output and it builds valid sql which executes properly.
I'm annotating here so we can later divide our users into those with and those without content, so we can execute a quicker delete process on non-content users.
There was a problem hiding this comment.
I changed this to two separate queries.
| """ | ||
| Delete users who haven't logged in for over three years. | ||
| """ | ||
| User = get_user_model() |
There was a problem hiding this comment.
This needs to be User = apps.get_model("auth", "User") in migrations similar to the previous one (0034)
There was a problem hiding this comment.
This is necessary because the delete_user_pipeline function needs an actual User instance vs. a historical model.
There was a problem hiding this comment.
If we cannot use the apps.get_model() here, probably we should refactor and change our approach. The migration needs to work the the model state and the time of its creation. If in the future the user model changes, the migration will most probably fail.
I would suggest to either refactor the migration in order to use methods compatible with the historical model (eg avoid properties and custom managers) or consider a different approach altogether.
| """ | ||
| Delete users who haven't logged in for over three years. | ||
| """ | ||
| User = get_user_model() |
There was a problem hiding this comment.
If we cannot use the apps.get_model() here, probably we should refactor and change our approach. The migration needs to work the the model state and the time of its creation. If in the future the user model changes, the migration will most probably fail.
I would suggest to either refactor the migration in order to use methods compatible with the historical model (eg avoid properties and custom managers) or consider a different approach altogether.
1 - get all users who we consider inactive (3 years since login)
2 - divide into users having content and users without content
3 - hard deletes non-content users using the
_base_manager4 - pushes other users through the deletion pipeline
5 - implements batching to manage resources