docs: rewrite README around point-de-rencontre model + add authorization brief
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sylvain Duchesne
@@ -0,0 +1,175 @@
|
||||
# Matrice d'autorisations et inventaire des requêtes
|
||||
|
||||
**Status:** Incubating — analyse en cours
|
||||
**Last updated:** 2026-05-18
|
||||
|
||||
## Context
|
||||
|
||||
Préalable au refactor multi-store ([brief](./multi-store-refactor.md)) et à toute évolution multi-user. La structure de stores NextGraph cible doit être *dérivée* de :
|
||||
|
||||
1. Une matrice d'autorisations (qui peut faire quoi sur quel type de donnée).
|
||||
2. Un inventaire des requêtes nécessaires (lectures, abonnements, écritures par écran).
|
||||
3. Les partitions naturelles qui en découlent (regroupements de données qui partagent autorisations *et* schéma d'accès).
|
||||
|
||||
Ce brief porte cette analyse. Il alimentera la décision finale sur la structure de stores.
|
||||
|
||||
## Cadre
|
||||
|
||||
### Acteurs (tous authentifiés)
|
||||
|
||||
- `Self` — propriétaire de la donnée (varie par type : auteur d'un message, titulaire d'un profil…)
|
||||
- `D` — Déclarant d'un événement (celui qui a inséré la référence dans Festipod ; pas l'organisateur réel)
|
||||
- `H` — Hôte d'un point de rencontre (celui qui l'a créé)
|
||||
- `I` — Inscrit à un point de rencontre
|
||||
- `C` — Connexion (« ami ») d'un autre acteur lié à la donnée
|
||||
- `U` — Utilisateur authentifié quelconque, sans relation à la donnée
|
||||
|
||||
### Verbes
|
||||
|
||||
- `créer`
|
||||
- `lire` (one-shot)
|
||||
- `s'abonner` (lecture longue / réactive)
|
||||
- `modifier`
|
||||
- `supprimer`
|
||||
|
||||
### Conventions
|
||||
|
||||
`✓` autorisé · `✗` interdit · `cond` autorisé sous condition (notée) · `—` sans objet
|
||||
|
||||
## Décisions cadre (acquises)
|
||||
|
||||
- **Tous les utilisateurs sont authentifiés.** Pas d'accès anonyme.
|
||||
- **Points de rencontre publics universels.** Tout utilisateur peut lire et s'abonner.
|
||||
- **Création de point de rencontre ouverte à tous.** Pas de prérequis (adhésion, invitation).
|
||||
- **Hôte = détenteur technique des droits d'écriture** sur un point de rencontre. À ce stade : 1 hôte par PdR, celui qui l'a créé.
|
||||
- **Adhésion à une communauté : hors périmètre actuel.** Le rôle « Membre de communauté » n'est pas analysé ici.
|
||||
- **Suivi de communauté ou d'utilisateur : hors périmètre actuel.** À reprendre quand la fonctionnalité de discovery par abonnement sera traitée.
|
||||
|
||||
## Matrice par type de donnée
|
||||
|
||||
### Point de rencontre
|
||||
|
||||
| Verbe | Self (= Hôte) | I (autre inscrit) | D (déclarant de l'événement parent) | U (utilisateur lambda) |
|
||||
|---|---|---|---|---|
|
||||
| créer | ✓ (l'acte de créer rend l'utilisateur hôte) | — | ✗ | ✓ (l'acte le rend hôte) |
|
||||
| lire | ✓ | ✓ | ✓ | ✓ |
|
||||
| s'abonner | ✓ | ✓ | ✓ | ✓ |
|
||||
| modifier | ✓ | ✗ | ✗ | ✗ |
|
||||
| supprimer | ✓ | ✗ | ✗ | ✗ |
|
||||
|
||||
**Notes :**
|
||||
- Pas de différenciation `C` (connexion de l'hôte) — les connexions sont un filtre d'affichage côté UI, pas un droit d'accès, puisque tout est public.
|
||||
- Le `D` n'a pas de droit particulier sur les PdR greffés sur son événement déclaré — il a juste déclaré la référence.
|
||||
|
||||
### Inscription à un point de rencontre
|
||||
|
||||
L'objet « Inscription » lie un utilisateur et un point de rencontre. Représente l'engagement à participer.
|
||||
|
||||
| Verbe | Self (l'inscrit) | H (hôte du PdR) | I (autre inscrit au même PdR) | U (utilisateur lambda) |
|
||||
|---|---|---|---|---|
|
||||
| créer | ✓ (s'inscrire) | ✗ | ✗ | ✓ (l'acte le rend inscrit) |
|
||||
| lire | ✓ | ✓ | ? **à trancher** | ? **à trancher** |
|
||||
| s'abonner | ✓ | ✓ | ? **à trancher** | ? **à trancher** |
|
||||
| modifier | ? **à trancher** (selon les champs modifiables) | ✗ | ✗ | ✗ |
|
||||
| supprimer | ✓ (se désinscrire) | ? **à trancher** (modération ? blacklist ?) | ✗ | ✗ |
|
||||
|
||||
**Questions ouvertes :**
|
||||
- **Visibilité de la liste des inscrits.** Cohérent avec « tout est public » : tous les utilisateurs voient qui s'est inscrit. Mais à confirmer — y a-t-il un cas où on veut cacher la liste (PdR à inscription confidentielle) ?
|
||||
- **Champs modifiables d'une inscription.** Booléen seul, ou champs additionnels (commentaire, statut "peut-être", nombre d'accompagnants) ?
|
||||
- **Modération par l'hôte.** L'hôte peut-il désinscrire un inscrit (= blacklist) ?
|
||||
|
||||
### Événement
|
||||
|
||||
| Verbe | Self (= D, déclarant) | H (hôte d'un PdR greffé) | U (utilisateur lambda) |
|
||||
|---|---|---|---|
|
||||
| créer | ✓ (l'acte rend déclarant) | — | ✓ (l'acte le rend déclarant) |
|
||||
| lire | ✓ | ✓ | ✓ |
|
||||
| s'abonner | ✓ | ✓ | ✓ |
|
||||
| modifier | ? **à trancher** | ? **à trancher** | ? **à trancher** |
|
||||
| supprimer | ? **à trancher** | ✗ | ✗ |
|
||||
|
||||
**Questions ouvertes :**
|
||||
- **Qui peut modifier un événement déclaré ?** Le déclarant seul (modèle propriétaire) ? Tout utilisateur (modèle wiki, pour compléter/corriger) ? Personne après création (modèle immuable, pour éviter les modifications mal intentionnées) ? Cette question est centrale pour le défi de déduplication évoqué dans le README — un modèle wiki facilite la convergence, un modèle propriétaire complique.
|
||||
- **Qui peut supprimer ?** Si le déclarant supprime, que deviennent les PdR greffés (orphelins ? supprimés en cascade ? l'événement reste mais marqué supprimé ?) ?
|
||||
|
||||
### Profil utilisateur
|
||||
|
||||
À déterminer : un seul objet ou split public/privé ?
|
||||
|
||||
| Verbe | Self | C (connexion) | U (utilisateur lambda) |
|
||||
|---|---|---|---|
|
||||
| créer | ✓ (à l'inscription) | — | — |
|
||||
| lire (partie publique) | ✓ | ✓ | ? **à trancher** |
|
||||
| lire (partie privée) | ✓ | ? **à trancher** | ✗ |
|
||||
| s'abonner | ✓ | ? | ? |
|
||||
| modifier | ✓ | ✗ | ✗ |
|
||||
| supprimer | ✓ (auto-destruction du compte) | ✗ | ✗ |
|
||||
|
||||
**Questions ouvertes :**
|
||||
- **Split public/privé ?** Le profil contient-il des champs réservés aux connexions ou à l'utilisateur seul (préférences, paramètres, email) ?
|
||||
- **Profil entièrement public ?** Cohérent avec « points de rencontre publics » : un visiteur peut voir le profil de l'hôte d'un PdR. Mais le détail (bio, photos, ville…) ?
|
||||
|
||||
### Connexion (lien d'amitié)
|
||||
|
||||
| Verbe | Self (A, demandeur) | Other (B, l'autre côté de la connexion) | U (utilisateur lambda) |
|
||||
|---|---|---|---|
|
||||
| créer (demande) | ✓ | — | — |
|
||||
| accepter | — | ✓ | ✗ |
|
||||
| lire (sa propre liste d'amis) | ✓ | — | — |
|
||||
| lire (la liste d'amis d'un autre) | — | — | ? **à trancher** |
|
||||
| s'abonner (à sa liste) | ✓ | — | — |
|
||||
| modifier | — | — | — |
|
||||
| supprimer (rompre la connexion) | ✓ | ✓ | ✗ |
|
||||
|
||||
**Questions ouvertes :**
|
||||
- **Bilatérale ou unilatérale ?** Le concept « connexion / ami » suggère bilatérale (les deux acceptent). À confirmer ; si oui, il y a deux objets distincts : `DemandeDeConnexion` (unilatérale) et `Connexion` (bilatérale).
|
||||
- **Visibilité de la liste d'amis.** Une connexion est-elle observable par des tiers ? « Marie est connectée à Bob » est-il public, restreint, ou privé ?
|
||||
|
||||
## Hors périmètre actuel
|
||||
|
||||
À reprendre quand ces concepts deviendront actifs :
|
||||
|
||||
- **Communauté d'intérêt** (membres, modération, création)
|
||||
- **Adhésion à une communauté**
|
||||
- **Liste curated** (création, partage, abonnement)
|
||||
- **Suivi d'utilisateur ou de communauté** pour discovery distribuée
|
||||
|
||||
## Inventaire des requêtes par écran
|
||||
|
||||
*À remplir une fois la matrice des autorisations stabilisée.*
|
||||
|
||||
Schéma prévu :
|
||||
|
||||
| Écran | Lectures one-shot | Abonnements | Écritures | Acteur déclencheur |
|
||||
|---|---|---|---|---|
|
||||
|
||||
Écrans à analyser (depuis [AGENTS.md](../../AGENTS.md#routing)) :
|
||||
|
||||
- `WelcomeScreen` `/`
|
||||
- `LoginScreen` `/login`
|
||||
- `HomeScreen` `/home`
|
||||
- `EventsScreen` `/events`
|
||||
- `CreateEventScreen` `/events/new`
|
||||
- `EventDetailScreen` `/events/:id`
|
||||
- `UpdateEventScreen` `/events/:id/edit`
|
||||
- `InviteScreen` `/events/:id/invite` (à voir si encore pertinent)
|
||||
- `ParticipantsListScreen` `/events/:id/participants`
|
||||
- `MeetingPointsScreen` `/events/:id/meeting-points`
|
||||
- `ProfileScreen` `/profile`
|
||||
- `UpdateProfileScreen` `/profile/edit`
|
||||
- `FriendsListScreen` `/profile/friends`
|
||||
- `ShareProfileScreen` `/profile/share`
|
||||
- `UserProfileScreen` `/users/:id`
|
||||
- `SettingsScreen` `/settings`
|
||||
|
||||
## Partitions naturelles dérivées
|
||||
|
||||
*À remplir une fois la matrice + l'inventaire stabilisés.*
|
||||
|
||||
Heuristique de dérivation : on regroupe dans un même store les données qui (a) partagent leur cellule d'autorisation pour les verbes d'écriture, et (b) sont accédées ensemble dans la majorité des requêtes (pour éviter de multiplier les abonnements).
|
||||
|
||||
## See Also
|
||||
|
||||
- [Brief : refactor multi-store](./multi-store-refactor.md) — consommateur principal de cette analyse
|
||||
- [README §Modèle fonctionnel](../../README.md) — source des acteurs et concepts
|
||||
- [Knowledge : data layer](../knowledge/data-layer.md) — état actuel mono-store
|
||||
Reference in New Issue
Block a user