stacker.news/api/typeDefs/notifications.js
ekzyis b379e7467f
Territory transfers (#878)
* Allow founders to transfer territories

* Log territory transfers in new AuditLog table

* Add territory transfer notifications

* Use polymorphic AuditEvent table

* Add setting for territory transfer notifications

* Add push notification

* Rename label from user to stacker

* More space between cancel and confirm button

* Remove AuditEvent table

The audit table is not necessary for territory transfers and only adds complexity and unrelated discussion to this PR.

Thinking about a future-proof schema for territory transfers and how/what to audit at the same time made my head spin.

Some thoughts I had:

1. Maybe using polymorphism for an audit log / audit events is not a good idea

Using polymorphism as is currently used in the code base (user wallets) means that every generic event must map to exactly one specialized event.

Is this a good requirement/assumption? It already didn't work well for naive auditing of territory transfers since we want events to be indexable by user (no array column) so every event needs to point to a single user but a territory transfer involves multiple users.

This made me wonder: Do we even need a table? Maybe the audit log for a user can be implemented using a view? This would also mean no data denormalization.

2. What to audit and how and why?

Most actions are already tracked in some way by necessity: zaps, items, mutes, payments, ...

In that case: what is the benefit of tracking these things individually in a separate table?

Denormalize simply for convenience or performance? Why no view (see previous point)? Use case needs to be more clearly defined before speccing out a schema.

* Fix territory transfer notification id conflict

* Use include instead of two separate queries

* Drop territory transfer setting

* Remove trigger usage

* Prevent transfers to yourself
2024-03-05 13:56:02 -06:00

136 lines
2.1 KiB
JavaScript

import { gql } from 'graphql-tag'
export default gql`
extend type Query {
notifications(cursor: String, inc: String): Notifications
}
extend type Mutation {
savePushSubscription(endpoint: String!, p256dh: String!, auth: String!, oldEndpoint: String): PushSubscription
deletePushSubscription(endpoint: String!): PushSubscription
}
type Votification {
id: ID!
earnedSats: Int!
item: Item!
sortTime: Date!
}
type ForwardedVotification {
id: ID!
earnedSats: Int!
item: Item!
sortTime: Date!
}
type FollowActivity {
id: ID!
item: Item!
sortTime: Date!
}
type Reply {
id: ID!
item: Item!
sortTime: Date!
}
type Mention {
id: ID!
mention: Boolean!
item: Item!
sortTime: Date!
}
type Invitification {
id: ID!
invite: Invite!
sortTime: Date!
}
type JobChanged {
id: ID!
item: Item!
sortTime: Date!
}
type EarnSources {
id: ID!
posts: Int!
comments: Int!
tipPosts: Int!
tipComments: Int!
}
type Streak {
id: ID!
sortTime: Date!
days: Int
}
type Earn {
id: ID!
earnedSats: Int!
minSortTime: Date!
sortTime: Date!
sources: EarnSources
}
type Revenue {
id: ID!
earnedSats: Int!
sortTime: Date!
subName: String!
}
type InvoicePaid {
id: ID!
earnedSats: Int!
invoice: Invoice!
sortTime: Date!
}
type Referral {
id: ID!
sortTime: Date!
}
type SubStatus {
id: ID!
sub: Sub!
sortTime: Date!
}
type TerritoryPost {
id: ID!
item: Item!
sortTime: Date!
}
type TerritoryTransfer {
id: ID!
sub: Sub!
sortTime: Date!
}
union Notification = Reply | Votification | Mention
| Invitification | Earn | JobChanged | InvoicePaid | Referral
| Streak | FollowActivity | ForwardedVotification | Revenue | SubStatus
| TerritoryPost | TerritoryTransfer
type Notifications {
lastChecked: Date
cursor: String
notifications: [Notification!]!
}
type PushSubscription {
id: ID!
userId: ID!
endpoint: String!
p256dh: String!
auth: String!
}
`