Given that you havetitle andcontent, I assume you're going to be accepting the fully rendered content (probably Markdown) of the notification in these fields. That means that CTAs will already be included incontent, I think. What role willactions play here?

The idea was to generate the title, content and actions using aDispatcher methodsimilar to SMTP.
thepayload field contains everything to have these three elements.

The reason why I had in mind to keep the actions separated from the body is that , based on the client (VSCode for example) we will not be able to handle the actions the same way. If we integrate the actions in the body using markdown it will not be compatible with everything.

So we just return labels and associated URLs and each client can handle it their way.

wdyt ?

If we integrate the actions in the body using markdown it will not be compatible with everything.

I think this is how it's already done, so we may need to change some things around later.
For now let's go with this until we reach any blockers.

Why doesorgMemberMe have privileges topolicy.ActionCreate inbox notifications?

From my RBAC understandingorgMemberMe is the current user.
Associatedto this part on the which we use thecurrentUser id.

In the definition of the ResourceInboxNotification, I assign thecurrentUser toInboxNotification using theWithOwner(currentUser.String()) method.

TL;DR -orgMemberMe is the owner of the resource in the test - and the owner of the resource should be able to access it.

I think we might wantmemberMe in here as well?

@defelmnq I understand why the current user should be able toread their own messages, but why should they be allowed tocreate new messages? That should be a system privilege.

These queries are identical except forread_at IS NULL; rather parameteriseFetchInboxNotificationsByUserID so you can explicitly filter for read/unread, or neither.

FetchUnreadInboxNotificationsByUserIDFilteredByTemplatesAndTargets could be refactored out according to the same pattern, too.

As I tried to iterate here and from what I found on the internet - I can't find a way to achieve that with sqlc.

sqlc, with narg, allow to have null parameters and optional values, with default values if we want - here the objective is a bit different as we want to completely change the query and theWHERE clause based on if a parameter is present or not.

If you have more idea, I could check.

You can alternatively just write a custom query yourself (seecoderd/database/modelqueries.go) and not need to deal with sqlc's idiosyncracies.

Targets do not reference a specific table.

Targets represent another entity which is connected to the notification - this field will be used to filter and search.

references the user that receives the notification.

From my RBAC understandingorgMemberMe is the current user.
Associatedto this part on the which we use thecurrentUser id.

In the definition of the ResourceInboxNotification, I assign thecurrentUser toInboxNotification using theWithOwner(currentUser.String()) method.

TL;DR -orgMemberMe is the owner of the resource in the test - and the owner of the resource should be able to access it.

I think we might wantmemberMe in here as well?

Where do we plan to use this query? If we're just displaying the unread notifications count in the UI, would it suffice to just calllen(GetUnreadInboxNotificationsByUserID()? My assumption is that the UI will be fetching unread notifications anyway.

This query will be called in two cases :

• An endpoint to get the number of unread notifications (without any notifications - just the count)
• Whenever you want to list the number of notifications (unread or not, filtered or not) - we'll include theunread_count

As a caller, it's not really clear to me what kind of UUID a target should be without looking at example usages. Could this be reworded slightly to be clearer?

Obligatory reminder to double-check migration number before merging!

Rather create a SQL type for this to get automatic codegen
Nit: make this lowercase to match other types' values

Nit: for future-proofing, rather drop the specificity here in case we add more filter options later:

Renamed ✅

@defelmnq I understand why the current user should be able toread their own messages, but why should they be allowed tocreate new messages? That should be a system privilege.