stacker.news/api/typeDefs/sub.js

69 lines
2.0 KiB
JavaScript
Raw Normal View History

import { gql } from 'graphql-tag'
2022-02-17 17:23:43 +00:00
export default gql`
extend type Query {
sub(name: String): Sub
2023-05-01 20:58:30 +00:00
subLatestPost(name: String!): String
2023-11-21 23:32:22 +00:00
subs: [Sub!]!
topSubs(cursor: String, when: String, from: String, to: String, by: String, limit: Limit): Subs
userSubs(name: String!, cursor: String, when: String, from: String, to: String, by: String, limit: Limit): Subs
}
type Subs {
cursor: String
subs: [Sub!]!
2023-11-21 23:32:22 +00:00
}
extend type Mutation {
2024-01-11 23:45:17 +00:00
upsertSub(oldName: String, name: String!, desc: String, baseCost: Int!,
postTypes: [String!]!, allowFreebies: Boolean!,
billingType: String!, billingAutoRenew: Boolean!,
moderated: Boolean!, hash: String, hmac: String, nsfw: Boolean!): Sub
2023-11-21 23:32:22 +00:00
paySub(name: String!, hash: String, hmac: String): Sub
2023-12-15 18:10:29 +00:00
toggleMuteSub(name: String!): Boolean!
toggleSubSubscription(name: String!): Boolean!
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 19:56:02 +00:00
transferTerritory(subName: String!, userName: String!): Sub
unarchiveTerritory(name: String!, desc: String, baseCost: Int!,
postTypes: [String!]!, allowFreebies: Boolean!,
billingType: String!, billingAutoRenew: Boolean!,
moderated: Boolean!, hash: String, hmac: String, nsfw: Boolean!): Sub
2022-02-17 17:23:43 +00:00
}
type Sub {
2023-11-21 23:32:22 +00:00
name: ID!
2023-07-27 00:18:42 +00:00
createdAt: Date!
2023-11-21 23:32:22 +00:00
userId: Int!
user: User!
desc: String
2023-07-27 00:18:42 +00:00
updatedAt: Date!
2022-02-17 17:23:43 +00:00
postTypes: [String!]!
allowFreebies: Boolean!
2023-11-21 23:32:22 +00:00
billingCost: Int!
billingType: String!
2023-12-08 20:02:00 +00:00
billingAutoRenew: Boolean!
2022-02-17 17:23:43 +00:00
rankingType: String!
2023-11-21 23:32:22 +00:00
billedLastAt: Date!
billPaidUntil: Date
2022-02-17 17:23:43 +00:00
baseCost: Int!
2023-11-21 23:32:22 +00:00
status: String!
moderated: Boolean!
moderatedCount: Int!
2023-12-15 18:10:29 +00:00
meMuteSub: Boolean!
nsfw: Boolean!
nposts(when: String, from: String, to: String): Int!
ncomments(when: String, from: String, to: String): Int!
meSubscription: Boolean!
optional: SubOptional!
}
type SubOptional {
"""
conditionally private
"""
stacked(when: String, from: String, to: String): Int
spent(when: String, from: String, to: String): Int
revenue(when: String, from: String, to: String): Int
2022-02-17 17:23:43 +00:00
}
`