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.
Follow-up surfaced during review of #118 (owner notification on
_sharesevents).Problem
The owner-notification suppression in
event_recipients(crates/mqdb-agent/src/database/sharing.rs,_sharesbranch) decides whether to skip notifying the resource owner by comparing the storedgranted_by(who created the grant) against the owner:On the unshare/delete path this proxy is wrong:
granted_byis the original grantor, not the actor performing the unshare. The delete path also computes recipients withsender = 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):
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 thangranted_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.