-
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
Init a tab for instructors to visualise habilitations #655
base: develop
Are you sure you want to change the base?
Conversation
un quick win est de faire des liens vers les habilitations depuis l'historique, je trouve ça un poill overkill de faire un onglet (alors qu'en vrai... c'est surtout important pour le demandeur et non l'instructeur) |
C'est important pour les instructeurs DGFIP de voir les habilitations sandbox & prod d'une demande. Je vais aussi faire le lien dans l'historique je pense. |
Pour le demandeur, lui montrer l'historique c'est un peu overkill je pense. Imo on doit revoir la présentation des demandes et des habilitations pour les séparer, et ça suffira à clarifier le tout. Les demandes draft, en cours et refusées dans une liste, et les habilitations validées et révoquées dans une autre. |
Lien qui existe dans l'historique de la demande côté instructeur.
Je n'ai pas d'avis sur l'historique entier, par contre pour le demandeur ça me semble pas déconnant d'avoir un listing des habilitations validées (pour voir les anciennes versions).
imo ça a de la valeur si l'organisation a > 1 demande, séparer les 2 notions je ne suis pas sûr que ça clarifie le tout, je pense même que ça aura l'effet inverse. Après, l'index des demandes/habilitations c'est à mon sens peu important, 99% des gens vont venir des notifications et donc arriver sur les demandes direct (ou tout du moins on doit pousser vers ça). tl;dr:
|
Non ? |
Oui faut le mettre, mais c'est déjà mentionné, suffit d'ajouter le lien justement (ce qui est faisable facilement vs refaire une page entière). |
Si dans la même page y'a écrit "Liste de mes demandes" et en dessous "Liste de mes habilitations", et que dans le cas où une liste est vide on affiche pas la section, je pense que ça sera pas confusant. |
Je pense que ça vaut le coup d'avoir une page qui résume simplement la liste des habilitations, versus les avoir noyées dans un historique d'allers retours qui peut être long, surtout dans les cas de la dgfip. |
as u ouiche, c'est je pense du détail pour les raisons évoquées plus haut (cf lien)
A/R qui n'existent pas vraiment vu qu'ils refusent et ne demande pas de modifications 😅 btw, sur le listing des habilitations, tu vas mettre toutes les habilitations, ou seulement la dernière ? pour une habilitation donnée tu vas omettre la demande dans la liste ? si non, tu vas mettre les 2 ? |
4d17c7b
to
ebbcd59
Compare
Let me cook for a while please, j'ai pas fini c'est juste un draft, on reprend la conversation lorsque je la passerait en PR 🙏 |
6fabd33
to
6d1fce0
Compare
3b80fe8
to
2ca006b
Compare
db305af
to
2e74cff
Compare
74893bb
to
3070820
Compare
Je m'occuperai de faire le display équivalent pour les demandeurs dans une PR followup, puis j'ajouterai carrément la séparation plus claire des demandes et habilitations dans l'UI dans une autre PR ensuite. |
(le "durant la demande N" est pas clair) |
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.
Y'a des petits trucs/questions mais globalement c'est OK
@@ -22,6 +22,10 @@ class Authorization < ApplicationRecord | |||
inverse_of: :authorization, | |||
dependent: :destroy | |||
|
|||
has_many :authorization_request_event, |
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.
has_many :authorization_request_event, | |
has_many :authorization_request_events, |
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.
(et en fait avec le commentaire du dessous imo ça peut jarter ici)
def approving_instructor | ||
authorization_request_event | ||
.where(name: 'approve') | ||
.order(created_at: :desc) | ||
.first | ||
.try(:user) | ||
end |
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.
def approving_instructor | |
authorization_request_event | |
.where(name: 'approve') | |
.order(created_at: :desc) | |
.first | |
.try(:user) | |
end | |
has_one :approved_authorization_request_event, -> { where(name: 'approve').order(created_at: :asc).limit(1) }, | |
class_name: 'AuthorizationRequest' | |
has_one :approving_instructor, | |
through: :approved_authorization_request_event, | |
class_name: 'User' |
pas sûr de la syntaxe. Je pense que c'est mieux d'avoir une relation
Sinon:
def approving_instructor
authorization_request_event
.where(name: 'approve')
.order(created_at: :asc)
.limit(1)
.first
.try(:user)
end
@@ -6,5 +6,5 @@ | |||
<p class="fr-callout__text"> | |||
<%= t(".text.#{type}") %> | |||
</p> | |||
<%= link_to t('.link.text', authorization_id: @authorization_request.latest_authorization.id), latest_authorization_path(@authorization_request), class:"fr-btn" %> | |||
<%= link_to t('.link.text', authorization_slug: @authorization_request.latest_authorization.slug), latest_authorization_path(@authorization_request), class:"fr-btn" %> |
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.
Si il y plusieurs validations le même jour, le slug sera DATE--1
. Pour moi il faut utiliser le created_at
<%= link_to t('.link.text', authorization_slug: @authorization_request.latest_authorization.slug), latest_authorization_path(@authorization_request), class:"fr-btn" %> | |
<%= link_to t('.link.text', authorization_created_at_date: @authorization_request.latest_authorization.created_at.to_date), latest_authorization_path(@authorization_request), class:"fr-btn" %> |
<%= time_tag authorization_request_event.created_at do %> | ||
<%= authorization_request_event.created_at.strftime("%d/%m/%Y") %> | ||
<% end %> | ||
<% if authorization_request_event.name == 'approve' %> |
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.
Je suis tiraillé sur le fait d'avoir mis ce morceau ici plutôt que dans le décorateur: d'un côté c'est plus simple et ça reste quand même une info importante à afficher, mais du coup on a une partie de logique vue dans le décorateur et ici.
En l'état ça me va, mais j'ai peur que ça devienne peu maintenable à l'avenir.
ceci est donc une simple remarque.
@@ -19,3 +20,37 @@ Fonctionnalité: Instruction: consultation d'une habilitation | |||
Quand je me rends sur une demande d'habilitation "API Entreprise" réouverte | |||
Alors il y a un bouton "Consulter l'habilitation" | |||
|
|||
Scénario: Je ne vois pas d'onglet pour consulter les habilitations d'une demande sans habilitations |
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.
Scénario: Je ne vois pas d'onglet pour consulter les habilitations d'une demande sans habilitations | |
Scénario: Je ne vois pas d'onglet pour consulter les habilitations d'une demande sans habilitation |
@@ -92,3 +92,12 @@ Fonctionnalité: Instruction: historique habilitation | |||
Et que je clique sur "Historique" | |||
Alors la page contient "Les données suivantes ont été modifiées par rapport aux informations pré-remplies du formulaire" | |||
|
|||
@DisableBullet | |||
Scénario: Je un lien vers l'habilitation sur l'évènement de validation |
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.
Scénario: Je un lien vers l'habilitation sur l'évènement de validation | |
Scénario: Je vois un lien vers l'habilitation sur l'évènement de validation |
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.
Ce test ne teste pas qu'il y a un lien.
Et la page contient un lien vers "/instructeur/habilitations/"
un truc du genre --^
@@ -182,6 +182,7 @@ | |||
applicant: authorization_request.applicant, | |||
authorization_request_class: authorization_request.definition.stage.previous_stages[0][:definition].authorization_request_class, | |||
data: authorization_request.data.presence || { 'what' => 'ever' }, | |||
created_at: authorization_request.created_at - 1.day |
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.
Pourquoi ?
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.
Par ce que sinon l'ordre des created_at n'est pas le bon. Ca faisait une ancienne authorization qui est plus récente. Et ça m'ennuyait dans l'ordre de display des habilitations dans la liste.
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.
Le souci ici est que c'est étrange d'avoir une demande d'habilitation qui est plus récente qu'une habilitation.
Possible de créer la demande 1 jour avant à la place ?
Closes https://linear.app/pole-api/issue/API2-340/afficher-les-habilitations-dune-demande