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

Init a tab for instructors to visualise habilitations #655

Open
wants to merge 12 commits into
base: develop
Choose a base branch
from

Conversation

JeSuisUnCaillou
Copy link
Contributor

Copy link

linear bot commented Jan 13, 2025

@skelz0r
Copy link
Member

skelz0r commented Jan 13, 2025

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)

@JeSuisUnCaillou
Copy link
Contributor Author

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.

@JeSuisUnCaillou
Copy link
Contributor Author

JeSuisUnCaillou commented Jan 13, 2025

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.

@skelz0r
Copy link
Member

skelz0r commented Jan 13, 2025

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.

Lien qui existe dans l'historique de la demande côté instructeur.

Pour le demandeur, lui montrer l'historique c'est un peu overkill je pense.

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 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.

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:

  1. j'ai peu d'avis sur l'index car je pense que ce n'est pas important
  2. vu que l'onglet a du potentiellement du sens pour le demandeur, ça ne coûte en effet pas plus cher de le mettre aussi pour l'instructeur

@JeSuisUnCaillou
Copy link
Contributor Author

Lien qui existe dans l'historique de la demande côté instructeur.

Non ?

@skelz0r
Copy link
Member

skelz0r commented Jan 13, 2025

Lien qui existe dans l'historique de la demande côté instructeur.

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).

@JeSuisUnCaillou
Copy link
Contributor Author

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.

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.

@JeSuisUnCaillou
Copy link
Contributor Author

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).

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.

@skelz0r
Copy link
Member

skelz0r commented Jan 13, 2025

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.

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.

as u ouiche, c'est je pense du détail pour les raisons évoquées plus haut (cf lien)

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).

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.

A/R qui n'existent pas vraiment vu qu'ils refusent et ne demande pas de modifications 😅
mais again, ça a du sens imo pour le demandeur dans la vue show, donc ça coûte pas plus cher pour l'instructeur (qui est censé être "expert" vu qu'il instruit)


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 ?

@JeSuisUnCaillou JeSuisUnCaillou force-pushed the display_all_habilitations_of_a_request branch from 4d17c7b to ebbcd59 Compare January 13, 2025 14:32
@JeSuisUnCaillou
Copy link
Contributor Author

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 🙏

@JeSuisUnCaillou JeSuisUnCaillou force-pushed the display_all_habilitations_of_a_request branch 3 times, most recently from 6fabd33 to 6d1fce0 Compare January 15, 2025 12:23
@JeSuisUnCaillou JeSuisUnCaillou force-pushed the display_all_habilitations_of_a_request branch 4 times, most recently from 3b80fe8 to 2ca006b Compare January 15, 2025 13:58
@JeSuisUnCaillou JeSuisUnCaillou force-pushed the display_all_habilitations_of_a_request branch 3 times, most recently from db305af to 2e74cff Compare January 15, 2025 15:04
@JeSuisUnCaillou JeSuisUnCaillou force-pushed the display_all_habilitations_of_a_request branch from 74893bb to 3070820 Compare January 15, 2025 15:35
@JeSuisUnCaillou JeSuisUnCaillou marked this pull request as ready for review January 15, 2025 15:39
@JeSuisUnCaillou
Copy link
Contributor Author

JeSuisUnCaillou commented Jan 15, 2025

J'ai pour l'instant uniquement géré l'information minimum que je pense qu'il faut pour que l'APIM de la DGFiP puisse bosser + quelques fixs en passant.

Des screens :

Screenshot from 2025-01-15 16-39-13

☝️ Consulter l'habilitation dans l'historique


Screenshot from 2025-01-15 16-39-01

☝️ Le show d'une habilitation


Screenshot from 2025-01-15 16-38-45

☝️ La liste des habilitations d'une demande

@JeSuisUnCaillou
Copy link
Contributor Author

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.

@skelz0r
Copy link
Member

skelz0r commented Jan 15, 2025

(le "durant la demande N" est pas clair)

Copy link
Member

@skelz0r skelz0r left a 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,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
has_many :authorization_request_event,
has_many :authorization_request_events,

Copy link
Member

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)

Comment on lines +71 to +77
def approving_instructor
authorization_request_event
.where(name: 'approve')
.order(created_at: :desc)
.first
.try(:user)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

app/policies/authorization_request_policy.rb Show resolved Hide resolved
@@ -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" %>
Copy link
Member

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

Suggested change
<%= 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' %>
Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pourquoi ?

Copy link
Contributor Author

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.

Copy link
Member

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 ?

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

Successfully merging this pull request may close these issues.

2 participants