Client Approval Authorization Consistency Automation: Approved On Screen, Still Pending in the Database

Two independently written copies of the same authorization rule rarely disagree on the easy cases — a master account is always allowed, a disabled team member is always denied, an unrelated client is always denied. Where two independent copies of a rule actually diverge is the edge case each author had to make a judgment call about without a specification to point to: what happens when the specific permission being checked was simply never recorded for this person at all. One author reasonably reads silence as "nothing was granted, so deny." Another, just as reasonably, reads the same silence as "nothing was ever taken away, so allow" — especially for a person who was invited before the fine-grained permission screen existed to record anything at all. Both readings are defensible in isolation. Only one of them can be correct once the exact same person hits both rules in the same afternoon.

The approval screen's own "Approve" and "Reject" buttons wrote directly from the browser to the underlying approvals table, protected only by the database's row-level security policy — no edge function sat between the click and the write. That policy's rule, confirmed directly from the fix's own inline comment describing the exact behavior it replaces, required the specific approval permission to be recorded as explicitly true; if it was never recorded at all, the policy treated the write as unauthorized and matched it to zero rows, exactly as row-level security is designed to do.

A separate authorization check, written independently inside the edge function used for the same product's calendar and deliverable decisions, encoded the identical underlying rule — but resolved the exact same "never recorded" case the opposite way: absent meant allowed, on the reasoning that an approver invited before a permissions panel even existed to record anything should not lose access purely because nobody ever explicitly re-confirmed it. Both readings appear in the product's own code comments as deliberate, reasoned decisions — made independently, at different times, by different code paths, with no shared function connecting them.

The consequence surfaces at exactly the point these two disagree: a client approver with the permission never explicitly recorded either way clicks "Approve" on the direct-write screen. The database policy denies the write and returns zero affected rows — no exception, no error, because a genuine zero-row result is also exactly what a legitimate, benign race between two people approving the same item at once looks like, and the calling code's own comment says as much: an update affecting no rows means someone else already won that race, so do nothing further and don't show an error. The screen's own success handler, which fires whenever the underlying request resolves without throwing, has no separate check distinguishing those two cases — it shows the same confirmation either way. The approver sees "Post approved successfully." The post's actual status never moved past pending.

The fix collapses both independent copies of the rule into one: a single predicate function that takes an organization and a client, and returns whether the calling, authenticated identity is allowed to approve for that pairing. The database's own security policy calls it directly. Every edge function calls the identical function too, through a small shared helper that authenticates as the CALLER (not as an administrative service account), so the database resolves the exact same identity the exact same way regardless of which code path asked. The unrecorded-permission case is now decided once, consistently, in the direction the edge function already used — an approver invited before permissions existed keeps working. And because decisions now run through dedicated functions that check this same predicate explicitly and raise a stated, human-readable refusal when it fails, a genuinely denied approver gets an actual, visible error message instead of a silent, indistinguishable false success.

A client contact, added as an approver before the agency's team ever opened the fine-grained permissions screen for that account, opens their approval queue and clicks "Approve" on a post. Before the fix, the click resolves without error, a "Post approved successfully" message appears, and the queue refreshes — while, underneath, the database's own security rule silently rejected the write because no explicit permission had ever been recorded for that specific approver, and the calling code's own race-condition handling treated the zero-row result as a normal, silent non-event. The post remains pending, invisibly, until someone else — staff, an admin, or an approver whose permission happens to be explicitly recorded — eventually approves it through a different path. After the fix, the identical click is evaluated by the one shared predicate, resolves as permitted (matching the edge function's own long-standing default for this exact case), and the post's status genuinely changes.

Centriu Axis's database security policy and every edge function that decides who may approve content now call the identical predicate function, authenticated as the same calling identity either way — closing a gap where the single most common unrecorded-permission case resolved two different ways depending on which code path handled the click, and where a denied write on one of those paths was visually indistinguishable from a genuine success.

This automation governs the internal consistency of Axis's OWN authorization rule for who may approve content, and how a denial is now surfaced — it does not change who your agency has decided should be allowed to approve, does not add new approval roles or permission types, and does not retroactively review approvals recorded before this fix shipped.

Writing an authorization rule once and re-implementing it independently wherever it's needed feels harmless when both authors are being careful — the actual defect here was never a case of either implementation being obviously wrong in isolation, both were reasoned, deliberate, defensible choices about an edge case with no shared specification. That is precisely the risk of a copied rule: it doesn't take carelessness to diverge, it only takes two different people making two different reasonable judgment calls, months apart, about the one case neither of them had a clear answer for. A rule called from a single, shared source cannot diverge from itself.