bobaboard/boba-backend

BobaBoard's Backend

boba-backend's Issues

Standardize variable names in server code

This is a catch-all bug for standardizing variable names in the server (feel free to propose more changes, and create an appropriate bug for each change as you decide to work on it/feel like doing some filing work):

• Make all string IDs specifically named thingStringId.

Prototype using Zod to add type safety to database queries

Zod is a library that allows us to define and validate the shape of a JavaScript object and automatically generates the corresponding TypeScript types.

We want to create Zod types for all the SELECT queries in our database to provide strong typings to the data coming out of the database.

Users star feed cursor needs more tests

If getUserStarFeed also returns the cursor, check whether the cursor is returned correctly. You might want to have jersey devil have TWO starred posts so you can do a page of 1 and get a "next page" pointer.

Originally posted by @essential-randomness in #38 (comment)

Add default realm member permissions to DB

• add realm permissions to DB and permissions.ts: post_on_realm, comment_on_realm, create_thread_on_realm, access_locked_boards_on_realm
• create REALM_MEMBER_PERMISSIONS array

Add permission to create invites for a Realm

• Update realm_user_roles to have a Realm id
• Create permission (instructions, possibly outdated).
  (Note: this is a "Realm" permission, so we'll need to create a RealmPermissions enum here.
• Add ensureRealmPermissions handler in handlers/permissions.ts
• Gate invites endpoint on the existence of the "create invite" permission.
• Move invites endpoints to be POST on /realms/invites

Allow associating a user with (one or more) realms

Add realm_users table with:

• user_id (referencing table users)
• realm_id (referencing table realms)

Unique index on realm_id, user_id (there shouldn't be more than one entry where both of these are the same)

Redesign permissions API structure

From Discord:

we have every type of permission in this object currently https://github.com/essential-randomness/bobaserver/blob/39ab7bd0f9c19a313a9b0c2bdf7071e869fec4cc/types/open-api/permissions.yaml#L3
but then the realm permissions are somewhere else
it's ok like this for now, we should just document it somewhere and also figure out whether we want a unified system

Create Endpoints for Importing BobaDexes feature.

See Allow creating a new bobadex from a gSheet #126 for more information.

Make sure the routes are receiving and returning the right id types

not a big one, but there are still a few cases where a number id is being passed when it should be an external id (ie- realm accessories). extending from standardizing variables

Remove fetching of Realm notifications from `/realms/slug/{realm_name}` endpoint

Problem

Fetching of Realm notifications is really slow and needs to be redesigned. Luckily, we already did some work splitting the "realm data fetching" endpoint (/realms/slug/{realm_name}) and the "realm notifications" endpoint (/realms/{realm_id}/notifications). However, the data fetching endpoint still uses the query that also fetches notifications, which is less than ideal.

Let's fix that!

The Players

• getRealmBoards is our entry point into the infamous "white whale query", the worst performing boba query that we have declared unfixable.
• This function is used in all realm data fetching queries, even the ones that don't need notifications.
• Likely, this wasn't changed even when I split the two endpoints cause I didn't want to redo the tests. I suspect that's going to be the "PITA" part of this fix.

Step by Step

• Zod the getRealmBoards query as data comes out of the database
• Zod the /realms/slug/{realm_name} endpoint
• Zod the /realms/{realm_id}/notifications endpoint
• Create a new (immediately-zodded) database query that gets all the boards in the realm with only the data effectively needed by the /realms/slug/{realm_name} endpoint
• Switch out the /realms/slug/{realm_name} endpoint to use that query
• Fix all tests (sorry)

Stretch

• Figure out if the getRealmBoards query is used in other parts of the codebase that don't need it.

The Future

While this gets fixed we'll be working on improving the performance of the notifications query by leveraging Redis.

Create an admin role for boba-tan and give her the `GoreMaster` role only in `!gore`

We made the GoreMaster role global so boba-tan could have the admin role permissions. We should have a specific admin role for that case.

Modify hide thread endpoint to allow for adding hidden thread note

• Change threads/:thread_id/hide endpoint HTTP method to PUT
• Allow for request body { hidden_thread_note: string | null }
• Update Open-Api doc for endpoint

Modify endpoint and related queries such that:

• If the thread is already hidden, just add note to database
• If thread is not yet hidden, hide thread and add note if one is included in the request body

Allow associating invite with specific realm

Should add realm_id for invite in account_invites table: https://github.com/essential-randomness/bobaserver/blob/main/db/init/000_init.sql#L29

Move responsibility for assembling invite URLs from the server to the client

The server should only return the invite code and let the client construct the invite URL. If we don't do this, then we leak info that the client is in charge of to the server.

Endpoints to be updated:

• https://github.com/essential-randomness/bobaserver/blob/fa369b141c304722553ca3c16987809751426dec/server/realms/routes.ts#L542
• https://github.com/essential-randomness/bobaserver/blob/fa369b141c304722553ca3c16987809751426dec/server/realms/routes.ts#L376

Add additional Users routes to improve RESTfulness

• Move the /realms/{realm_id}/notifications endpoint to users/@me/notifications/realms/{realm_id}
• Create an endpoint users/@me/permissions/realms/{realm_id} and have it return the user's realm permissions instead of /realm/{realm_slug}

Update server to check member realm permissions

• update getUserPermissionsForRealm query to check that user is a member of the realm and append default realm member permissions
• update ensureBoardAccess handler to check for accessLockedBoardOnRealm permission
• update open-api permissions schema RealmPermissions enum
• gate logged in routes as appropriate with ensureRealmPermission (will have to include realm_id in req for any gated route, or extract it from existing info)
• update tests

Add typescript strict mode to boba-backend

Turn `ensureNoIdentityLeakage` into a middleware

Allow get invites endpoint to return all invites filtered by status

[Currently the get /realms/realm_id/invites/ endpoint is setup to only return the pending invites for the realm.]

The "right" way of doing it would be to return all the invites (with pagination), then have a status get param which allows to filter by status. For example, our request could be:

/realms/v0/invites?status=PENDING

to only get the pending invites.

Two things that I didn't add in the design that prevents us from doing this the right way:

1. We don't have a status enum we return with the invite. This is because I thought we'd just calculate it with expired_at and didn't want to duplicate the information, but I was wrong. We should have a status field which has at least: PENDING, ACCEPTED, EXPIRED (potentially for the future REVOKED).
2. We don't have pagination for this endpoint, which is not a huge deal for now if we're returning only pending invites, but will be at some point in the future.

Originally posted by @essential-randomness in #53 (comment)

Standardize server error messages

many error messages are non-descriptive and unhelpful (ie: 500 error)

Allow associating a note with hidden threads

• Add note field to user_hidden_threads table
• Add hiddenThreadNote to DbThreadType type definition
• Add hiddenThreadNote to ThreadSummary type definition

Add an example of a very long comment thread to our test data

There are times when we might need something like this to test the frontend:

Add ability to control rate of new user account creation

Currently all Realm invites have the potential to create a new user account.

Before the implementation of additional Realms beyond Fandom Coders, we need the ability to control how many new Boba users a given Realm's leadership team has the ability to create in a given time period. Possible options for the design of this mentioned so far include:

a) Splitting off sign-up invites from Realm invites entirely and giving them separate endpoints.
or
b) Simply adding a boolean to check whether an invite has the power to create an account in the invites table

Some previous history of this issue can be found here: #46

Further consideration of the design of the invite flow is required to resolve this issue.

Extend invite endpoint to add user to the corresponding Realm

Endpoint in question

• Changes endpoint to simply be POST on /users/invites/
• Document endpoint using OpenAPI spec
• Attempt retrieving user by email to check for existence
• If user does not exist, create it, then go to next step
• If user exists, associate it with the realm in the current invite

Extend GET thread endpoint to return hidden thread note

Endpoint in question

• Update thread-by-string-id SQL query to SELECT the note, if exists
• Add hiddenThreadNote to the returned data from makeServerThreadSummary
• Update the Open-Api schema for ThreadSummary

Add endpoint to list all invites issues for a Realm

• Create GET endpoint for realms/invites
• Define API schema
• Implementation