School database structure

[florian-lefebvre]

Je propose qu'on parte sur le modèle suivant (on ne parle pas ici des join tables) :

graph LR
    User <--> Member <--> School

Les modèles ne prennent pas en compte les PRs en cours qui peuvent modifier certains schemas.

type UserRole = 'user' | 'developer' | 'admin'

interface User {
  id: number
  email: string
  password: string
  rememberMeToken?: string
  roles: UserRole[]
  accesses: HasMany<Access>
  members: HasMany<Member>
  createdAt: DateTime
  updatedAt: DateTime
}

type MemberRole = 'student' | 'teacher' | 'parent' | 'staff'

interface Member {
  id: number
  firstName: string
  lastName: string
  birthDate: DateTime
  roles: MemberRole[]
  user: BelongsTo<User>
  school: BelongsTo<School>
  createdAt: DateTime
  updatedAt: DateTime
}

interface School {
  id: number
  name: string
  members: HasMany<Member>
  contact: {
    email: string
    phone: string
  }
  address: {
    street: string
    city: string
    state: string
    zip: string
  }
  rne: string
  createdAt: DateTime
  updatedAt: DateTime
}

J'oublie sûrement plein de champs, n'hésitez pas à faire part de vos idées et je mettrai à jour ce message.

cc @op-ent/backend

[Micorksen]

Pour vérifier les RNEs, je te laisse voir mon issue #11.

[florian-lefebvre]

On verra lors de l'impémentation, là on est juste sur un schema théorique. Tu sais s'il existe une API de l'état avec tous les RNEs ?

[Micorksen]

Hello, oui j'ai même fait l'issue pour inclure l'endpoint.

[NonozgYtb]

Je propose une amélioration qui inclus les académies (car un ENT peut comprendre plusieurs académies)

interface School {
    // On garde le reste
    national_id: string // Pour l'internationalisation, je pense que "national_id" est plus pertinent que RNE mais cela ce résume au même, exemple : 0120000A
    academy: Academy
} 

interface Academy {
    id: string // exemple : 3df8e3284e39b
    name: string // exemple : "Académie de Ville"
    national_id: string // exemple : "ac_ville" (utile par exemple pour le domaine, la route, le portail spécifique de l'académie
    schools: HasMany<School> // Il serait peut-être pertinent de relié dans l'autre sens mais à mon avis, pas obligatoire
    members: HasMany<Member> // Je le mets car c'est logique mais cela ferait avec une mise en prod. beaucoup d'entrée, complexe et lourd (niveau performances) à manipuler.
}

Aussi, quel est le modèle de Access ?

[florian-lefebvre]

https://github.com/op-ent/api/blob/main/app/Models/Access.ts mais je l'ai pas spécifié parce que ça ne concerne pas les établissements

[florian-lefebvre]

Quel est l'intérêt de stocker l'académie ? Je veux dire, qui va avoir accès à l'information (usecase) ?

[Micorksen]

Quel est l'intérêt de stocker l'académie ? Je veux dire, qui va avoir accès à l'information (usecase) ?

Bah pour trouver les établissements par académie.

[florian-lefebvre]

J'ai bien compris mais en pratique, qui va chercher au sein d'op-ent les établissements par académie ? En sachant qu'un utilisateur n'a accès qu'aux établissements dont il est membre. Si vous avez des vrais usecases, dites moi, je suis pas du tout contre mais je préfère implémenter que ce qui est utile

[florian-lefebvre]

La date de naissance, le prénom et le nom devraient plutôt être sur le modèle utilisateur. Ces informations ne changent pas d'un établissement à l'autre...

Je suis pas vraiment d'accord, et ce pour plusieurs raisons :

• N'importe qui peut register, même des gens qui n'appartiendront à aucun établissement (compte développeur par exemple), donc demander des informations personnelles ne me semble pas utile + problème pour le RGPD : comment justifier de la récolte de ses données si inutiles ?
• Les informations renseignées par les utilisateurs peuvent être fausses, ce qui peut poser des problèmes. En plus il me semble que toutes ces informations (en tout cas prénom + nom) viennent d'un système de l'éducation nationale et sont donc corrects à 100% (ou presque mais vous avez capté l'idée)

Dites moi ce que vous en pensez

[florian-lefebvre]

Oui je vois...ça me semble une bonne idée le model UserDetails

[Micorksen]

La date de naissance, le prénom et le nom devraient plutôt être sur le modèle utilisateur. Ces informations ne changent pas d'un établissement à l'autre...

Je suis pas vraiment d'accord, et ce pour plusieurs raisons :

• N'importe qui peut register, même des gens qui n'appartiendront à aucun établissement (compte développeur par exemple), donc demander des informations personnelles ne me semble pas utile + problème pour le RGPD : comment justifier de la récolte de ses données si inutiles ?
• Les informations renseignées par les utilisateurs peuvent être fausses, ce qui peut poser des problèmes. En plus il me semble que toutes ces informations (en tout cas prénom + nom) viennent d'un système de l'éducation nationale et sont donc corrects à 100% (ou presque mais vous avez capté l'idée)

Dites moi ce que vous en pensez

Bah après, comme je le proposeais, utiliser l'authentification des utilisateurs avec le PIA ou bien EduConnect, et approuver manuellement les développeurs.

[florian-lefebvre]

Le problème c'est que tout le monde a pas accès à ses services là. Perso j'y ai eu accès qu'en terminale