Generic problematic dialogues table + Workspace interactions overview

[Cold-A-Muse]

Fixes HAAS-371

In this PR

• Revamped the backend for the query used to fill up the issues table. Now focuses on teams (dialogues) and the frequency negative interactions are filled in
• Initial workspace sessions (feedback) overview <- can be found at http://localhost:3002/dashboard/b/{CUSTOMER_SLUG}/dashboard/feedback

Known bugs:

• Sometimes when you click an interaction the underlying table where the user is known, the row somehow loses info in regard to team and turns the first column into Anonymous Cell.

This happens with and without adjusted filter. This is probably caused by GetWorkspaceSessions randomly being called again the moment the interaction modal is opened. query params both before and after opening modal are the same so this is not the cause of the re-render

Adding a skip: isOpenModal fixes this but instead it would cause a re-render whenever the modal is closed and it is a hacky way that doesn't solve the actual problem.

Logging the sessions (useState) I notice that after clicking an interaction the dialogue + followUpAction fields are changed to null for the session in the state. However, the data seems to be available in the newly fetched query.

I tried swapping to opening the modal without changing the route using boolean value instead but it still re-renders 😭

Edit: Seems that changing network-policy to 'no-cache' from 'network-and-cache' fixed the issue of both the rerender and disappearing data 😬. However, this also doesn't seem like the ultimate fix as you obv rather cache pages if they remain the same.

Edit 2: Swapping to the default fetch-policy (cache-first) also seems to fix the issue and still supports caching. I am not sure why network-and-cache acts so strange though and it itches my brain.

Edit 3: Actually doesn't seem to work as when you move between pages when you go back to your first page where u clicked on some entries the data is gone again :/

[linear[bot]]

HAAS-371 Simple Dialogue Table (API)

## Description We want to have our issues table now reflect "negative" dialogues (initially, we can make it a toggle if need be). The idea is that it stays quite similar to the current Issues table, but instead of Issues, it just shows negative Dialogues ranked by their `urgencyScore` (formerly called `actionRanking` for issues). The `urgencyScore` is calculated through a heuristic (currently implemented in `IssueService.calculateScore`). We need to do this now on the Dialouge scope rather than an Issue scope. * [ ] Implement a similar function for the Dialogue as is done in Issues

[JMitnik]

So there were two bugs, essentially, plaguing your cache:

• The followUpAction.id was expected to be an integer ID, but a string was returned by the backend. Strangely enough, this did not crash, but it did confuse the Apollo cache. I removed it temporraily, as fixing it has implications for every place where we use the node-entry. We need to cast this id to a string.
• Because you adjusted the SessionFragment, everywhere where it is used now, it expects the dialogue.id. That means that if the server suddenly returns dialogue: null for a session somewhere, it will store that in the cache. So imagine this: on timestamp A, you request dialogue, and you get your dialogue (because the API returns this). This was the case for SessionConnection. A session however does not know how it should resolve a dialogue by itself, so when the modal is opened, it is unable to resolve a dialogue and returns null, which GraphQL interprets as an "update" (the dialogue was nullified). Thus, it will set that to the cache, and invalidate the query that was made earlier. So on closing the modal, the invalidated query needs to be reran, except it can now fallback on the cache and sees that dialogue is empty. I adjusted such that Session can fetch dialogue by itself (and should use the findUnique query so Prisma can batch 10 calls (from 10 sessions) to one.