vegard
1faef972dd
Migrering 0005 samler kanban-kort, kalenderhendelser, faktoider og notater til én felles messages-tabell med view-config-tabeller. Actors og topics erstattes av unified entities-tabell. - 0005_meldingsboks.sql: messages utvides med title/pinned/visibility, kanban_card_view + calendar_event_view + message_reactions opprettes, entities erstatter actors+topics, gamle tabeller droppes - seed_dev.sql: oppdatert til meldingsboks-modell + 5 test-entiteter med graf-relasjoner - API-ruter: kanban/kalender/notater bruker messages + view-config - Dokumentasjon: meldingsboks feature-spec, oppdatert arkitektur, kunnskapsgraf, jobbkø, konseptdokumenter og proposals Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
47 lines
2.8 KiB
Markdown
47 lines
2.8 KiB
Markdown
# Forslag: Personlig workspace
|
|
|
|
## Ide
|
|
Hver bruker får et implisitt, privat workspace med alle verktøyene et vanlig workspace har — kanban, kalender, notater, graf-koblinger. Alt kan kladdes privat og flyttes til et delt workspace når det er klart.
|
|
|
|
## Hvorfor er dette interessant?
|
|
- Redaksjonsmedlemmer trenger et sted å jobbe uforstyrret — research, kladder, oppgavelister
|
|
- `visibility = 'private'` på meldingsbokser løser private notater *innenfor* et workspace, men gir ikke en egen arbeidsflate med egne kanban-brett, kalendere og graf
|
|
- Et personlig workspace gir full fleksibilitet: private kanban-brett for personlige oppgaver, privat kalender, private research-notater med graf-koblinger — alt med eksisterende infrastruktur
|
|
|
|
## Hva det bygger på
|
|
- Workspace-modellen (RLS, workspace_members)
|
|
- Meldingsboks (alt er allerede workspace-scopet)
|
|
|
|
## Åpne spørsmål
|
|
|
|
### Opprettelse
|
|
- Automatisk ved brukerregistrering, eller on-demand?
|
|
- Navnekonvensjon for slug: `user-{authentik_id}` eller `personal-{display_name}`?
|
|
|
|
### Flytt mellom workspaces
|
|
Hovedutfordringen. En meldingsboks som flyttes fra personlig til delt workspace krever:
|
|
- `nodes.workspace_id` endres
|
|
- `graph_edges` som refererer til noden — flyttes med, eller brytes?
|
|
- Svar (`reply_to`-kjeden) — følger med, eller forblir i kilde?
|
|
- `kanban_card_view` / `calendar_event_view` — peker på strukturer (kolonner, kalendere) i kilde-workspacet
|
|
|
|
Mulige strategier:
|
|
1. **Kopier, ikke flytt** — opprett ny node i mål-workspace, behold original i personlig. Lenke mellom dem med edge.
|
|
2. **Flytt atomisk** — flytt noden og alle avhengigheter i én transaksjon. Komplekst men rent.
|
|
3. **Del, ikke flytt** — endre `visibility` fra `'private'` til `'workspace'` uten å bytte workspace. Krever at personlige og delte meldinger kan sameksistere i samme workspace (allerede støttet).
|
|
|
|
Strategi 3 er enklest og allerede implementert via `visibility`-kolonnen. Et personlig workspace trengs da bare hvis brukeren vil ha *helt separerte* verktøy (eget kanban-brett, egen kalender).
|
|
|
|
### Workspace-switcher
|
|
- Vises personlig workspace i workspace-switcheren?
|
|
- Visuelt skille mellom personlige og delte workspaces?
|
|
|
|
### Kvoter og TTL
|
|
- Eget disk-/lagringsbudsjett per personlig workspace?
|
|
- Strengere TTL for å unngå at personlige workspaces vokser ubegrenset?
|
|
|
|
### Alternativ: "Visibility er nok"
|
|
Det kan hende at `visibility = 'private'` på meldingsbokser innenfor delte workspaces dekker 90% av behovet. Et personlig workspace er da overkill — brukeren jobber bare privat i det delte workspacet og deler når klar. Verdt å evaluere etter at visibility er i bruk en stund.
|
|
|
|
## Innsats: Lav (workspace-opprettelse) / Middels (flytt-mellom-workspaces)
|
|
## Wow-faktor: Middels
|