Ux/dat 409/new design authorization request card

[Isalafont]

---

---

Full Page

---

Quand l'utilisateur est dans la section Toutes celles de l'organisation, le nom du demandeur de la demande (autre que celle du current user) s'affiche.

[linear]

DAT-409 Ajouter des informations sur les cartes de demande / habilitation

[Isalafont]

close DAT-418 ETQ D, si mon habilitation est validée et qu'un jeton ou un accès est disponible, je peux récupérer mon jeton / mon accès sur le dashboard de Datapass

[JeSuisUnCaillou]

Beau boulot déjà !

[Isalafont]

@evaspae Pourras tu me valider l'ordre de présentation des habilitation sur le Dasboard (Demandes à modifier, Demandes en cours d'instruction, demandes en brouillon, Mes habiliations)
J'ai trouvé cet ordre présent sur la page "Accueil" du Figma, mais trouvé un ordre de présentation différent dans une autre page du Figma 🫣

[jbfeldis]

GG, c'est stylé !

J'ai laissé quelques commentaires plutôt axés sur le ruby dans erb, ça rejoint surtout les commentaires de Valentin sur l'utilisation plus poussée des decorators

[JeSuisUnCaillou]

@Isalafont Pour moi on est bons, je laisserait @jbfeldis valider après avoir échangé avec toi sur sa review.

[JeSuisUnCaillou]

Moi j'ai déjà dit que ça m'allait.
Je vois qu'il reste des commentaires de @jbfeldis non resolus, vous en avez parlé à l'oral ?

[Isalafont]

J'ai fait des commentaires mais ils sont restés en pending... ARGHHH

[Isalafont]

@jbfeldis

on ne pourrait pas utiliser la forme de render qui fonctionne avec une collection ? ça éviterait de répéter les conditions vu qu'on est dans le cas ou rendre une collection vide ça fait exactement ce qu'on veut

J'ai tenté d'utiliser une collection mais j'ai l'impression que ça complexifie le code également au niveau du fichier app/views/dashboard/_authorization_requests.html.erb pour traiter la collection.
Les habilitations ne se classent plus dans leurs sections respectives.
Je pense que ça meriterait peut être de s'y plonger d'avantage dans un ticket de refacto ?

[Isalafont]

@jbfeldis

on peut aussi pousser ça dans le decorator pour se débarrasser des conditions dans les vues (ça vaut pour la plupart des conditions qui suivent dans ce partial)

je n'ai pas regardé les decorators dans le projet donc ce n'est ptet pas aligné avec le style du projet mais on pourrait éventuellement en discuter

(bon moi j'avoue que j'aime pas les conditions et encore moins dans les vues 👴 😄 )

Jusqu'a présent dans le décorator, il y a surtout des methods helpers, je ne suis pas certaine que de déplacer une condition a une seule branche soit réellement un plus niveau lisibilité ?

Mais je suis d'accord qu'il y a peut être des questions à se poser quand à notre utilisation des decorators et ce que l'on doit y mettre ou pas ?

J'ai déplacé dans le decorator la condition précédente qui pour le coup améliore la lisibilité.

[JeSuisUnCaillou]

let's go ! :D

[skelz0r]

Jusqu'a présent dans le décorator, il y a surtout des methods helpers, je ne suis pas certaine que de déplacer une condition a une seule branche soit réellement un plus niveau lisibilité ?

Mais je suis d'accord qu'il y a peut être des questions à se poser quand à notre utilisation des decorators et ce que l'on doit y mettre ou pas ?

Tout ce qui est utilisé uniquement dans la vue et intrinséquement lié au modèle ça part dans le decorateur pour moi. Ensuite je fais confiance à nos règles de lint pour nous alerter dès que ça devient trop gros.

[evaspae]

C'est bon pour moi ! 👍