synops/docs/erfaringer/access_propagering.md
vegard f52d23de54 Fix: synops-respond propagerer access til chat-deltakere
Bot-svar var usynlige fordi node_access ikke ble propagert.
Alle deltakere i chatten (owner/member_of) får nå reader-access
til svar-noder. Erfaringsnotat dokumenterer mønsteret.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-20 06:06:58 +00:00

53 lines
1.6 KiB
Markdown

# Erfaring: Access-propagering for chat-meldinger (mars 2026)
## Problemet
Bot-svar i chatter var usynlige for brukere. Meldingene ble
skrevet til PG, men brukerne hadde ingen `node_access`-rad
for dem. Frontend filtrerte dem bort som "hidden".
## Rotårsak
`synops-respond` (og `chat-reply.sh`) opprettet svar-noder med
`visibility: 'hidden'` og `belongs_to`-edge til chatten, men
propagerte ikke `node_access` til chat-deltakerne.
Maskinrommets intention-system (create_node med context_id)
propagerer access automatisk. Men verktøy som skriver direkte
til PG må gjøre det selv.
## Fiks
Etter INSERT av belongs_to-edge, propager access til alle
deltakere i chatten:
```sql
INSERT INTO node_access (subject_id, object_id, access, via_edge)
SELECT e.source_id, $reply_id, 'reader', $edge_id
FROM edges e
WHERE e.target_id = $communication_id
AND e.edge_type IN ('owner', 'member_of')
ON CONFLICT DO NOTHING
```
## Lærdommer
1. **Alle som skriver til PG direkte må propagere access.**
Maskinrommets intention-system gjør det automatisk, men
CLI-verktøy, scripts og direkte INSERT gjør det ikke.
Det er lett å glemme — og resultatet er usynlige noder.
2. **Test med en annen bruker.** Utvikleren ser egne noder
uansett (created_by). Buggen er bare synlig for *andre*
deltakere i chatten.
3. **WebSocket-filtrering forsterker problemet.** Selv om
noden er i PG, filtrerer portvokteren den bort for
brukere uten access. Dobbel usynlighet.
## Påvirket kode
- `tools/synops-respond/src/main.rs` — fikset
- `scripts/chat-reply.sh` — hadde allerede propagering
- Alle andre verktøy som skriver noder med belongs_to-edge
bør sjekkes