Skip to content

share event: owner not notified when an admin unshares a grant the owner created themselves #119

Description

@fabracht

Follow-up surfaced during review of #118 (owner notification on _shares events).

Problem

The owner-notification suppression in event_recipients (crates/mqdb-agent/src/database/sharing.rs, _shares branch) decides whether to skip notifying the resource owner by comparing the stored granted_by (who created the grant) against the owner:

if granted_by != Some(owner.as_str()) && !recipients.contains(&owner) {
    recipients.push(owner);
}

On the unshare/delete path this proxy is wrong: granted_by is the original grantor, not the actor performing the unshare. The delete path also computes recipients with sender = None, so the actual unshare actor is not available at recipient-computation time.

Consequence: if an owner self-shares a grant (granted_by == owner) and an admin later unshares it, the owner is not notified — even though someone else changed their share set. That contradicts the spirit of #110 ("notify the owner when someone else shares/unshares their resource"), though it matches the current literal doc wording ("skipping the owner when they performed the share themselves").

Truth table for unshare (actor = who performs the unshare):

grant created by unshared by desired current
owner owner suppress suppress ✓
owner admin notify owner suppress ✗
admin admin notify owner notify ✓
admin owner suppress notify (minor over-notify)

Suggested fix

Thread the actual unshare actor (sender) through the delete-path recipient computation (share_revoke → clear_grant → delete_grants → delete → event_recipients), and base owner-suppression on actor == owner rather than granted_by == owner. This also corrects the admin-granted/owner-unshared over-notification row.

Scope

Deliberately left out of #118 (more invasive than that PR's fix, and the current behavior matches documented intent). Low severity: no confidentiality impact — only a missed/extra notification.

Verified by quorum + counter-test during #118 review; cascade unshare per-record owner resolution itself is correct.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions