sidelinja/server
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
server/docs/proposals/personlig_workspace.md
vegard 1faef972dd Meldingsboks-migrasjon: universell diskusjonsprimitiv + entities 
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>
2026-03-15 15:32:15 +01:00

2.8 KiB
Raw Blame History

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