peter/siftlode
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(tests): correct the deny-vs-delete rationale in the invites test file

Browse Source 
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.
This commit is contained in:
peter
2026-09-02 00:15:21 +02:00
parent 2cba6b9fca
commit 1fe24d374a
1 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend/tests/test_admin_invites.py
+8 -6
View File
@@ -1,9 +1,11 @@
"""Deleting a whitelist / access-request entry (admin). """Deleting a whitelist / access-request entry (admin).
Deny keeps the row so a refused person cannot immediately re-ask; delete forgets the address Deny records an auditable decision and keeps the row; delete forgets the address outright, for an
outright, for an approval added by mistake or one that is no longer wanted. The one hard rule is approval added by mistake or one that is no longer wanted. Neither stops the person asking again —
that an entry backed by an account is NOT deletable here: `is_allowed` reads this row, so removing `upsert_pending_invite` reopens a denied row as pending, and a deleted one comes back as a fresh
it would silently revoke a live user's access. 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 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): 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 # A pending row is deletable too — "drop this without recording a decision" is a different
# from Deny, which keeps the row precisely so the person cannot immediately re-ask. # choice from Deny, which stores a decision (status, decided_by) and mails the requester.
admin = make_user(email="admin@example.com", role="admin") admin = make_user(email="admin@example.com", role="admin")
db.add(Invite(email="asker@example.com", status="pending")) db.add(Invite(email="asker@example.com", status="pending"))
db.commit() db.commit()