-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add domain logic for push notifications #1778
Conversation
b803411
to
17838ac
Compare
if (safe && safe.owners.includes(args.account)) { | ||
authorizedSafesToSubscribe.push(safeToSubscribe); | ||
continue; | ||
} | ||
|
||
const delegates = await this.delegatesRepository | ||
.getDelegates({ | ||
chainId: safeToSubscribe.chainId, | ||
safeAddress: safeToSubscribe.address, | ||
delegate: args.account, | ||
}) | ||
.catch(() => null); | ||
|
||
// Upsert delegate | ||
if ( | ||
delegates && | ||
delegates.results.some(({ delegate }) => delegate === args.account) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These checks need to be disucssed as it is still unclear whether we allow anyone to subscribe to queue-related events. I'd suggest we keep with owner/delegate only and adjust later if needed as it's a small adjustment if necessary.
360de40
to
8bae9d4
Compare
a14ce77
to
b59e7f7
Compare
subscribers.map((subscriber) => { | ||
return messageConfirmationBuilder() | ||
.with('owner', subscriber.subscriber) | ||
.build(); | ||
}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we also test the scenario where a subset of the subscribers have signed? I think currently all the test escenarios are all-or-none signatures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in 663d901.
continue; | ||
} | ||
|
||
throw new UnauthorizedException(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we log this error (the account signer not being a owner/delegate of one of the target Safes), wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in 663d901.
I think this PR needs a rebase onto the source branch 🙂 |
Leverages the `NotificationsDatasource` to `getSubscribersWithTokensBySafe` for the relative `TransactionEventType` and `enqueueNotification`s accordingly: - Add `INotificationsRepositoryV2` behind a feature flag: - `enqueueNotification` - `upsertSubscriptions` - `getSafeSubscription` - `getSubscribersWithTokensBySafe` - `deleteSubscription` - `deleteDevice` - Extend `HooksRepository` with `onEventEnqueueNotifications` with respective entities. - Add `transaction_hash` query to `getIncomingTransfers` and propagate changes/add tests. - Locate previously domain-relative logic for notifications in domain, e.g. entities and builders. - Add approriate test coverage.
Summary
This adds the relative logic to the domain for enqueuing notifications to subscribers when the relevant hook event is received.
It leverages the
NotificationsDatasource
togetSubscribersWithTokensBySafe
for the relativeTransactionEventType
andenqueueNotification
s accordingly.Changes
INotificationsRepositoryV2
behind a feature flag:enqueueNotification
upsertSubscriptions
getSafeSubscription
getSubscribersWithTokensBySafe
deleteSubscription
deleteDevice
HooksRepository
withonEventEnqueueNotifications
with respective entities.transaction_hash
query togetIncomingTransfers
and propagate changes/add tests.