-
Notifications
You must be signed in to change notification settings - Fork 2
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
Feat/dat 260/etq i je peux revoquer une habilitation validee #137
Feat/dat 260/etq i je peux revoquer une habilitation validee #137
Conversation
eaebd84
to
f973054
Compare
Dans le cas d'une révocation :Enregistrement.de.l.ecran.2024-03-27.a.15.12.08.movDans le cas du refus, l'utilisation de la même popup (review le wording)Enregistrement.de.l.ecran.2024-03-27.a.15.14.39.mov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quelques petites remarques mais surtout cette histoire de denial. J'ai un peu survolé la review parce que je connais pas tout votre système.
Concrètement là tel quel ca ne me convient pas.
J'explique :
- Avant cette PR il y a 2 classes identique
IntructorModificationRequest
etDenialOfAuthorization
qui correspondent chacune à un cas d'usage différent. C'est un choix technique qui a été fait (et potentiellement ca se challenge).
Du coup si on se base sur l'existant la logique voudrait de créer une nouvelle classe dédié au revoke (on est sur un autre event, sur un autre objet, qui a des conséquences métier autre).
Si on estime que c'est pas DRY et pas clair, alors on crée une notion abstraite genre EventWithReason
(à challenger comme naming) et on l'utilise partout.
MAIS, on ne fait pas un entre les deux à base de "ici on unifie" et "ici on unifie pas". Le fais que le revoke et le refuse évoque plus ou moins la même chose (alors que c'est différent) est suffisament confusant pour qu'on isole pas uniquement ces 2 events dans le code parce que les termes se ressemblent.
Il faut être en mesure au premier coup d'oeil de savoir quelles sont les caractéristiques discriminentes pour savoir si on utilise telle classe ou telle classe ou une notion abstraite. Là franchement c'est pas clair.
Perso, je m'en fiche du choix technique final qui est fait, je souhaite juste qu'il soit cohérent de facon transverse sur la code base.
@Un3x En effet, on avait en tête de faire un Je pense que ça peut attendre le lancement de reborn. Ca nous permettra d'avoir un peu + de recule sur les différents types de |
Moi cette décision @mehdi-farsi elle me convient, mais dans ce cas on utilise pas le DenialOfAuthorization, on en fait un autre custom et autant de custom dont on a besoin jusqu'à ce qu'on arrive au point où on sait le nomner correctement. Comme ca on reste cohérent. |
Pas de problème. C'est un peu hors de cette PR qui est déjà à 27 fichiers. Je te propose de faire cela dans une autre PR dans la foulée. |
Pour info j’avais décidé de faire N modèles pour les raisons suivantes:
1. Pour sortir des statistiques c’est plus simple
2. C’est plus simple d’augmenter les infos sur des modèles distincts qu’un modèle générique. Typiquement sur le request change ajouter des champs à modifier, le refus des templates spécifiques/type de raison, etc..
3. C’est plus simple niveau wording/i18n de manipuler des modèles différents
4. C’est plus clair de manipuler un denial/instructor request change, qu’une classe générique
5. C’est assez simple de créer des nouveaux modèles en rails (1 ligne de commande), l’argument de la complexité technique
Pour moi le plus important reste la clarté, ce qui a clairement fait pencher la balance vers le N modèles.
Et je vous cache pas que le spectre du god pattern de la v1 a aussi eu son effet.
…On Wed 27 Mar 2024 at 15:13, Mehdi FARSI ***@***.***> wrote:
@Un3x <https://github.com/Un3x> En effet, on avait en tête de faire un
Event::Reason.
Je pense que ça peut attendre le lancement de reborn. Ca nous permettra
d'avoir un peu + de recule sur les différents types de
authorization_request_event.entity et de faire en sorte d'avoir une
abstraction qui couvre la majorité des cas (avec de bons namings 😊).
—
Reply to this email directly, view it on GitHub
<#137 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJYPYCGH7WMWPMBUYU2PNDY2LHYXAVCNFSM6AAAAABFIVX4ZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTGAZDKNRWHA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
Désolé mais je ne suis pas d'accord. Cette PR introduit le problème en utilisant le modèle à tord. J'ai pas d'avis sur la solution technique et je ne me rangerai pas d'un côté ou de l'autre alors que je ne travaille pas activement sur le projet, Encore une fois j'essaye d'apporter un point de vue extérieur. Je m'en fiche que le mur soit bleu ou vert, mais pas à moitié bleu et à moitié vert. Concernant la taille des PRs, c'est un autre sujet. Aucun problème à ce que vous affiniez le découpage des chantiers et l'explosiez en plusieurs PRs de facon plus itérative. Encore une fois, sous réserve que l'ensemble de ce qui est livré soit cohérent. |
@Un3x Il y a clairement un sujet de refacto global sur les naming d' Je vais à la place, créer une nouvelle table à associer à un event de révocation en mode |
@Isalafont @mehdi-farsi @SchweisguthN voici mes retours dans le cas d'une révocation : Pour la page d'accueil de l'instructeur :
Sur la page de l'habilitation :
Modale pour le motif de révocation :
Page d'accueil, une fois que la révocation est validée :
|
65059a3
to
dec6643
Compare
@evaspae En premier retour concernant directement le wording de la modal, j'ai effectué les changements suggérés. Je me suis permis de changer le titre car nous sommes sur une habilitation et non une demande à ce moment là. |
Pour Information @evaspae, J'ai rajouté du margin top sur tous les flash message. |
Top, ça me va très bien ! Merci |
Sur les maquettes, l'emplacement est le même partout donc pas uniquement sur la page instructeur. |
Du coup, on va devoir faire une passe globale sur l'ensemble des pages pour vérifier que le design des flash messages soit bon partout. On laisse comme ça dans cette PR et on crée un ticket dans la foulée histoire de ne pas polluer cette PR! |
@skelz0r une review stp 🙏 |
Vous attendez une review ici btw ? |
En effet :-) |
Comme discuté ce matin, il faudrait ajouter un message dans la modale sur les statuts "refusée" et "révoquée" : "attention, cette action est irréversible" Je valide le wording globale de la modale + l'emplacement du flash message |
- Add factories for revoke event - Check in models line 36 if condition if correct ? `return if %w[approve refuse request_changes revoke].exclude?(name) && entity_type == 'AuthorizationRequest'` - Decorators
a311c7a
to
86c7f1d
Compare
Étrange je n'ai pas eu d'emails 🙄 |
- Api Entreprise is in charge to send emails
86c7f1d
to
b8e58d4
Compare
authorization_request.denial_ids, | ||
authorization_request.modification_request_ids, | ||
authorization_request.changelog_ids, | ||
authorization_request.message_ids, | ||
authorization_request.authorization_ids, | ||
authorization_request.revocation_ids |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah clairement mieux
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's ship it!
instruction.revoke_authorization_requests.create.success.title | La demande d'habilitation %{name} a été révoquée
révoquée
et un statusen cours de mis à jour
en même tempsvalidée