tn12787 / catalog Goto Github PK

• Frontend (#115)
• Backend (#118)

Update the actions on the db to also add an entry to the audit log table
Update the UI to collect the relevant logs for that team and display

Although #17 would be a start for this, as soon as people are paying for our product we need to offer them bare-minimum support.

Possible pro-active solutions:

• Sentry (to capture exceptions as they happen)
• Intercom (so users can message us directly)
• Freshdesk (for more structured support, though this likely won't be necessary initially)

We need at least something in place, it's not good enough to be ad-hoc with paying customers.

• #135
• #134
• #133
• #132
• #131

Blocked by #19 and optionally #20

We need a concrete way to remind users when their tasks are about to become overdue.

Could be TZ sensitive.

We need a basic implementation of Stripe's webhooks etc and integrate that with plans to start collecting payments from users.

We need to design a marketing site for our product, and implement the technical side to go from "hey I landed here" to "hey I'm a customer on the pro trial".

We should implement a push/desktop notification mechanism for tasks/reminders.

Means we need an extra onboarding step, but other than that doesn't change much!

We'll have a new email template, and some new onboarding logic.

Both in-app and on marketing site - will become extremely important as we get spending on ads to figure out why we aren't converting.

Possible sources:

• Hotjar
• Google Analytics
• Segment
• Heap

When a notification is generated, it should be possible to deliver it by email too. Users should be able to disable this.

Support for notifications in UI for users to manage.

Integrate with reminder job to create notifications once a day.

Only support tasks becoming overdue for now.

We need to decide what each plan can have, and how much each should cost.

ditto.

Tasks

• Make sure OpenGraph stuff works
• Canonical URLs
• Add a sitemap
• Check LIghthouse scores

Basic contact mgmt API, reserved for teams, bound to a team, and a table UI for managing them. Allow tasks to be "assigned" to a contact, e.g. outsourced.

Data model for contacts:

• name
• email
• telephone
• website
• notes? - info about them, whether they did a good job or not
• tags / type / skills / something(producer, mastering, photographer, social media mgr) etc.

Keen to get some feedback here!

Right now, we handle most of our errors by raising proper exceptions to return the correct error code over the wire.

However, we don't catch Prisma errors appropriately.

We need to determine a good way to catch these errors at scale (without API routes growing out of control).

From an email

From the app

The email thinks that the task is overdue, despite the notification message being different.

Now that #23 is taking shape, we should start disabling features that a user with a particular plan doesn't have.

Of currently-built features, this includes:

• #101
• #102
• #103
• #104
• #105
• #106

Restrictions need to apply on both the frontend but also at the API level.

Kind of a coda to #100.

Right now all plans have access to all features.

However there are some features that will create very large numbers of database rows (release task events, for example), that won't be visible to some product tiers anyway, creating bloat for us and $$$ spent on infra for no reason.

Our goal right now is not to upsell free-tier users (much) to the mgr plan as they likely as artists won't be able to buy the product.

So any features that are "off" for the free plan should not exist in the database.

Preliminary List

• Release Task Events (comments, etc)
• Audit Log-type stuff
• Default Contact Labels for a workspace ? not too bad, like 20 rows per workspace at most

As we grow there'll likely be more stuff we need to manage here, but we just need to make sure we do this.

We really don't want 20M rows of data nobody is likely to see.

As per some studies done on here, it'd be great to get some onboarding stuff into place for users.

This isn't super necessary for LA1, but reduces the amount of pain early adopters will have getting on the platform.

Also did a UX study into Loom's onboarding (as they have a similar slant to us) and some new things should be doable.

We should do two things:

Add a new user screen (for setting workspace name initially and stuff)
Include a popover for onboarding like this:

Not sure exactly what to put but ideally all of this could be solved with as little extra db data as possible.

Creating an artist? (easy! artists > 0)
Creating a release? (can't do it without an artist!)
Adding team info? Should be done at welcome screen, else check for updated at later than created at.
Adding some tasks? Should be possible to see with a quick release query.

Ideally we could add some more state or something here to ensure once this journey has been completed, we don't show this again.

Proposed flow:

1. Admin sends invite from UI
2. User clicks link in email
3. If not signed in, sign in and then come back to verify page
4. If not a match / invalid / etc, sign out and show error
5. If a match, redirect to home and show success toast

Basically, If I'm a member of workspace A and workspace B, I shouldn't be able to go to /tasks/[some task in workspace b] if i'm currently viewing workspace A.

From an API perspective it's not illegal, it's just weird UX.

Messages

Did some first tests
work wells
in de pdf some bugs I found.
It might need some more features for me personally before I would use it. Compared to the other tools i'm using right now.
maybe more segments or task possibilities within the release part.

Bugs

PDF with screencaps

Suggestions and features

• #83
• #80
• Artists need an avatar
• Can't edit artists
• #78
• #79

Could invite users to view/edit something?

Use case: Want to involve external contact with one item of release schedule, but not give them team membership of any kind.

Could add FK to release / task table as 'viewers' and one for 'editors' maybe? (keeps permissions out of it and is explicit) OR

Could have ExtraAccess table associated with release / task with an email and some permissions.

required for #4 and many other things

Gonna take a swing at cracking some UI bugs.

• Client Error on Tasks Page
• Bad summary data rendering on new Release Wizard
• Can't access Notifications popover on mobile at all
• Various Mobile issues
• The team logo by default in the manage team page doesn't match the default Avatar.
• 'View in planner' in the release card doesn't work
• Flashing outline on the Account Switcher Button
• #61
• Looking at a release in the planner makes no sense (Task-type view?)
• Z-Index issues on Popovers

We need jobs that can be run occasionally.

This package could be useful for building this out with GH Actions.

Enables #21

Right now, we have a wizard-style data-entry experience for entering release information. This works great for entering data about a release we've already started planning, have dates for, or are backfilling.

We should design an experience focused around what was discussed here, for new releases.

This way it can be super low-touch:

As a user, I want to enter my release's target date and basic info, and pre-fill all the sub tasks and generate the summary page according to a plan, while letting me change each of the dates in the plan, and having all the others update relative to release.

As a user, I would like to be able to select from several plans when coming up with a new release.

As a user, I would like to be able to make my own plans, to re-use for subsequent releases.

ditto.

Deferring this for now as a wider accessibility pass will need doing later.

We need to come up with a solid way of testing our system.

Do we use a test database and go e2e straight away?

Or do we test API and FE separately for now?

Some things

ditto.

blocked by #125

Heroku doesn't support connection pooling for free -> we should move to DigitalOcean, which gives us pgbouncer.

Basically as soon as we start connecting to postgres we're overloading the connection limit.

Currently there isn't much we do on the frontend to react to errors like 404 when we receive them for the primary data-fetching method for a page, such as /tasks/[task_id].

I'm thinking there's gotta be a way to make some of those tasks pre-fetch on the server.

The initial setup for Server-Side queries was done according to the guide, but there currently aren't any queries being made server-side explicitly.

On top of that, we need something other than the default pages for 404 / 500 / etc.

Error Message

Explore integrations to build into product. Baseline view here is that it's not useful for teams unless we can integrate it with stuff people already have.

Calendars

• Google Calendar
• O365 Calendar
• Notion?

General Connections

• Slack (Channel per release, task updates go in there?)
• Email (baseline)
• Spotify (for stats on artists / releases?)
• Distributors (if they have an API)
• Some kind of invoicing stuff?

Maybe could hire a tech writer for some of this?

We need a basic documentation site for users. Could be rolled into this Next.js app and statically rendered?