User Story or Bug Summary:
I'd like to delete sandbox accounts which have had their activation keys expired. To facilitate this, I'm delivering code that will add some filters to the Users view in Django admin. We will now be able to filter by Active (users with Active status), Inactive (users with Inactive status), and Inactive (expired activation key) (users with inactive status and an expired activation key). By selecting the third option, it will be simple to delete all never-activated users as required by the ticket.
What Does This PR Do?
This PR adds a new filter to the Users admin view as described above.
What Should Reviewers Watch For?
If you have any knowledge of places we have unit tested this kind of code, let me know! I would love to add unit tests for this, but was unsure of where that would go or how it would work. Open to pairing as well.
You should test this by creating new accounts locally, to have a variety of cases in your User pool:
An active account
An account that once was active, but is no longer (should be fine to do this with Fred by deactivating him temporarily)
An account that is inactive and whose key is expired (in reality this would be done by clicking on the activation link after the expires date, but you can just update the status of the activation key toexpired`)
An account that is inactive, whose key status is created, and whose key expires is in the past
An account that is inactive, whose key status is created, and whose key expires is in the future
It wasn't straightforward to adjust the expires value of the activation key to be in the past, so you can adjust the logic in the filter temporarily to test that case by changing datetime.today() to something like datetime.today()+timedelta(days=7).
We would expect that Active would give you account 1, Inactive would give you 2, 3, 4, 5, and Inactive (expired activation key) would give you 3, 4.
What Security Implications Does This PR Have?
None
What Needs to Be Merged and Deployed Before this PR?
None
Any Migrations?
[x] No migrations
Submitter Checklist
I have gone through and verified that...:
[x] This PR is reasonably limited in scope, to help ensure that:
It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
There isn't too much of a burden on reviewers.
Any problems it causes have a small "blast radius".
It'll be easier to rollback if that becomes necessary.
[x] This PR includes any required documentation changes, including README updates and changelog / release notes entries.
[x] All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
[x] All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
[x] Reviews are requested from both:
At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
Any relevant engineers on other projects (e.g. BFD, SLS, etc.).
[x] Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
Please review the standards every few months to ensure you're familiar with them.
JIRA Ticket: BB2-3232
User Story or Bug Summary: I'd like to delete sandbox accounts which have had their activation keys expired. To facilitate this, I'm delivering code that will add some filters to the Users view in Django admin. We will now be able to filter by
Active(users with Active status),Inactive(users with Inactive status), andInactive (expired activation key)(users with inactive status and an expired activation key). By selecting the third option, it will be simple to delete all never-activated users as required by the ticket.What Does This PR Do?
This PR adds a new filter to the Users admin view as described above.
What Should Reviewers Watch For?
If you have any knowledge of places we have unit tested this kind of code, let me know! I would love to add unit tests for this, but was unsure of where that would go or how it would work. Open to pairing as well.
You should test this by creating new accounts locally, to have a variety of cases in your User pool:
expiresdate, but you can just update the status of the activation key toexpired`)created, and whose keyexpiresis in the pastcreated, and whose keyexpiresis in the futureIt wasn't straightforward to adjust the expires value of the activation key to be in the past, so you can adjust the logic in the filter temporarily to test that case by changing
datetime.today()to something likedatetime.today()+timedelta(days=7).We would expect that
Activewould give you account 1,Inactivewould give you 2, 3, 4, 5, andInactive (expired activation key)would give you 3, 4.What Security Implications Does This PR Have?
None
What Needs to Be Merged and Deployed Before this PR?
None
Any Migrations?
Submitter Checklist
I have gone through and verified that...:
READMEupdates and changelog / release notes entries.TODOand/orFIXMEcomments, which include a JIRA ticket ID for any items that require urgent attention.