From 3f900101c62d31008139123589d1e62f02bbe94f Mon Sep 17 00:00:00 2001 From: Carlo Costino Date: Wed, 8 Nov 2023 10:05:22 -0500 Subject: [PATCH 1/2] Update ADR-0003: InvitedUser Expirations This changeset updates ADR-0003 to clarify the work a bit more and remove a couple of extraneous steps. The previous draft included provisions for creating a whole separate `expired` field, which is unnecessary. h/t to @xlorepdarkhelm and @stvnrlly for catching this and asking about it! --- docs/adrs/0003-implementing-invite-expirations.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/adrs/0003-implementing-invite-expirations.md b/docs/adrs/0003-implementing-invite-expirations.md index 051710528..84ed69f37 100644 --- a/docs/adrs/0003-implementing-invite-expirations.md +++ b/docs/adrs/0003-implementing-invite-expirations.md @@ -3,7 +3,7 @@ | CREATED DATE | LAST UPDATED | STATUS | AUTHOR | STAKEHOLDERS | | :---: | :---: | :---: | :---: | :---: | -| 06/06/2023 | 09/15/2023 | Accepted | @ccostino | @GSA/notify-contributors | +| 06/06/2023 | 11/08/2023 | Accepted | @ccostino | @GSA/notify-contributors | ## CONTEXT AND PROBLEM STATEMENT @@ -30,7 +30,8 @@ has more specific details.) We'd like to adjust the API and data model so that invited users are no longer deleted from the system and are instead tracked as active or expired. When an -invite is expired, we'd like to be able to re-invite the person. +invite is expired, we'd like to be able to show that in the invited users +screen and provide the ability re-invite the person. ### SECURITY COMPLIANCE CONSIDERATIONS @@ -55,8 +56,6 @@ This is the approach we've considered for implementing this change: dates for when they need to expire. This would involve the following potential changes: - - Add an `expired` flag to the `InvitedUser` model - - Change the `delete_invitations` scheduled job to `expire_invitations` and change its behavior to check for `InvitedUser` objects that are older than 24 hours and flip the `expired` flag to `True`. @@ -66,9 +65,11 @@ This is the approach we've considered for implementing this change: changes. - Make sure the API responses that provided `InvitedUser` objects/data - included the new `expired` field and status. + included the new `expired` status. - - Update all tests related to `InvitedUsers` to account for the new behavior. + - Update all tests related to `InvitedUsers` to account for the new behavior; + this may require making a new test or two to check explicitly for the new + `expired` status. The pros in making this change: From c364c8fdabc0fb99d90c1e1bd71f7225daf201ae Mon Sep 17 00:00:00 2001 From: Steven Reilly Date: Wed, 8 Nov 2023 10:10:58 -0500 Subject: [PATCH 2/2] Update docs/adrs/0003-implementing-invite-expirations.md --- docs/adrs/0003-implementing-invite-expirations.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adrs/0003-implementing-invite-expirations.md b/docs/adrs/0003-implementing-invite-expirations.md index 84ed69f37..8d44204c3 100644 --- a/docs/adrs/0003-implementing-invite-expirations.md +++ b/docs/adrs/0003-implementing-invite-expirations.md @@ -58,7 +58,7 @@ This is the approach we've considered for implementing this change: - Change the `delete_invitations` scheduled job to `expire_invitations` and change its behavior to check for `InvitedUser` objects that are older than - 24 hours and flip the `expired` flag to `True`. + 24 hours and change the status type to `expired`. - Add an additional `INVITE_EXPIRED` status to the API and include it in the `INVITED_USER_STATUS_TYPES` enum. This will be necessary for future UI