NotificationRecipient
Corex\Notifications\NotificationRecipient · class · Core layer
How a notification is targeted, and the single predicate that decides whether the current actor may see it. Every read, count, and badge re-checks {@see canBeSeenBy()} (spec 072 FR-002/FR-003) — knowing a notification’s id grants nothing. Targeting is by user or ability, never by hard-coded WordPress role (FR-006).
Public API
Section titled “Public API”forUser(int $userId): self
Section titled “forUser(int $userId): self”forUsers(array $userIds): self
Section titled “forUsers(array $userIds): self”forAbility(string $ability): self
Section titled “forAbility(string $ability): self”forAssigned(string $sourceType, string $sourceId, int $assigneeId, string $managerAbility): self
Section titled “forAssigned(string $sourceType, string $sourceId, int $assigneeId, string $managerAbility): self”forCategoryAdmins(string $ability): self
Section titled “forCategoryAdmins(string $ability): self”canBeSeenBy(int $userId, callable $userCan): bool
Section titled “canBeSeenBy(int $userId, callable $userCan): bool”The one visibility decision. $userCan is the actor’s capability check (e.g. a closure over current_user_can), injected so this stays pure and testable.
targetsUserDirectly(int $userId): bool
Section titled “targetsUserDirectly(int $userId): bool”Whether this notification names $userId personally, rather than reaching them through an ability they happen to hold. Narrower than {@see canBeSeenBy()} on purpose: an ability-targeted notification is visible to every holder of that ability but is nobody’s personally, so the “assigned to me” view must not use visibility as its filter or it would just repeat the inbox for any manager.