Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formulaire de création de boîte mail : corriger les messages d'erreur pour e-mail déjà utilisé (+ gérer les langues) #281

Open
jblagadec opened this issue Jul 1, 2024 · 3 comments
Assignees

Comments

@jblagadec
Copy link
Collaborator

Image

Si on crée une nouvelle boite mail pour un utilisateur, en saisissant la même "adresse e-mail principale" qu'un utilisateur déjà créé, on obtient ce message d'erreur :
"Un objet Mailbox avec ces champs Local_part et Domain existe déjà."
De plus il est toujours en français dans une page en anglais.

=> Il faut rendre ce message plus compréhensible pour un utilisateur.

On peut remplacer par :
FR : Une boîte mail a déjà été créée avec cette adresse e-mail principale. Veuillez en saisir une autre.
EN : A mailbox already exists with this main email address. Please enter another one.

@jblagadec jblagadec changed the title Formulaire de création de boîte mail : corriger les messages d'erreur pour e-mail déjà utilisé Formulaire de création de boîte mail : corriger les messages d'erreur pour e-mail déjà utilisé (+ gérer les langues) Jul 2, 2024
@daproclaima
Copy link
Collaborator

Pour moi, on ne devrait pas avoir à la fois l'API qui retourne une erreur traduite dans la langue de l'utilisateur et le surlignage du champ erroné associé à l'erreur API.

Car cela signifie que le code du frontend devra, pour chaque erreur API, comparer celle-ci à une Regex dans la langue correspondante avant de pouvoir chercher quel champ surligner...

La solution la plus stupide que j'avais développée pour associer une erreur API (rien qu'en anglais) à un champ était complexe et je l'ai au final retirée.

Discutons-en quand les priorités le permettent @sdemagny.

@daproclaima
Copy link
Collaborator

Voir ce commentaire en PR #286 expliquant pourquoi nous aurions plutôt besoin d'erreurs API en une langue unique

@jblagadec
Copy link
Collaborator Author

Deux solutions possibles, à trancher :

  1. Solution actuellemennt utilisée : l'API renvoie une erreur mais qui n'a pas le texte attendu. Donc le front transforme cette erreur, y compris en adaptant la langue
  2. Solution suggérée par Sabrina : l'API renvoie directement les bons messages d'erreur dans les bonnes langues, en retournant y compris le champ concerné

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants