From 1fe24d374a52bcfca28fec5d35c9ac1065bdd821 Mon Sep 17 00:00:00 2001 From: npeter83 Date: Wed, 2 Sep 2026 00:15:21 +0200 Subject: [PATCH] docs(tests): correct the deny-vs-delete rationale in the invites test file MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Round 4's only finding: the file header and one comment still said Deny stops a refused person re-asking. It does not — upsert_pending_invite reopens a denied row as pending — and the delete_invite docstring in the same branch already says so. The real difference is that Deny records an auditable decision and mails the requester; Delete forgets the address. --- backend/tests/test_admin_invites.py | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/backend/tests/test_admin_invites.py b/backend/tests/test_admin_invites.py index 96d35173..2786aa4e 100644 --- a/backend/tests/test_admin_invites.py +++ b/backend/tests/test_admin_invites.py @@ -1,9 +1,11 @@ """Deleting a whitelist / access-request entry (admin). -Deny keeps the row so a refused person cannot immediately re-ask; delete forgets the address -outright, for an approval added by mistake or one that is no longer wanted. The one hard rule is -that an entry backed by an account is NOT deletable here: `is_allowed` reads this row, so removing -it would silently revoke a live user's access. +Deny records an auditable decision and keeps the row; delete forgets the address outright, for an +approval added by mistake or one that is no longer wanted. Neither stops the person asking again — +`upsert_pending_invite` reopens a denied row as pending, and a deleted one comes back as a fresh +request. The one hard rule is that an entry backed by an account is NOT deletable here: this row is +that account's approval gate, and orphaning it would strand someone who could then neither sign in +nor be approved. """ from sqlalchemy import select @@ -118,8 +120,8 @@ def test_an_admin_emails_address_is_also_reported(db, make_user, as_user, monkey def test_deleting_a_pending_request_forgets_it(db, make_user, as_user): - # A pending row is deletable too — "not now, and don't keep the record" is a different decision - # from Deny, which keeps the row precisely so the person cannot immediately re-ask. + # A pending row is deletable too — "drop this without recording a decision" is a different + # choice from Deny, which stores a decision (status, decided_by) and mails the requester. admin = make_user(email="admin@example.com", role="admin") db.add(Invite(email="asker@example.com", status="pending")) db.commit()