Ajoute un model claim pour gérer les demandes

[jbfeldis]

Ajoute un model "claim" pour garder une trace minimum des demandes des utilisateurs.

Cela permettra de faire du support mais aussi de garder nos options ouvertes concernant des fonctionalités plus avancées (se connecter pour désactiver la mise à jour auto de son QF par exemple).

[skelz0r]

Globalement il n'y a rien de bloquant sur le code, modulo le naming de ce modèle que je ne comprends pas.

Pourquoi Claim ? Qu'est-ce que cela incarne exactement ? En voyant les attributs on dirait plutôt du logging de requête QF (donc renommer QuotientFamialialRequestLog ?)

[jbfeldis]

Globalement il n'y a rien de bloquant sur le code, modulo le naming de ce modèle que je ne comprends pas.

Pourquoi Claim ? Qu'est-ce que cela incarne exactement ? En voyant les attributs on dirait plutôt du logging de requête QF (donc renommer QuotientFamialialRequestLog ?)

@skelz0r L'idée c'est de représenter une demande (j'ai traduit par "claim" parce que ça évitait "request" et que c'est lié à des droits donc ça me semblait pas mal), il y a un but de log mais aussi de support et potentiellement de fonctionnalités avancées (du suivi du côté usager par exemple mais aussi une potentielle fonctionnalité usager pour désactiver la mise à jour auto).

Ceci étant dit je prends avec plaisir un meilleur naming :D

[skelz0r]

QuotientFamilialClaim / QuotientFamilialRequest ?

D'un point de vue controller ça me semble logique d'avoir quotient_familial_request#create ?

[JeSuisUnCaillou]

"Request" c'est un peu ambigü, au début je pensais que ça représentait une collectivité qui request le QF d'un particulier. J'imaginerait ça plus logique de parler d'envoi de quotient familial que de request.

Je propose :

• QuotientFamilialTransfer
• QuotientFamilialShipment
• QuotientFamilialSending
• ou plus golbal DataTransfer (par ce qu'il y'a + que le QF)

[skelz0r]

"Request" c'est un peu ambigü, au début je pensais que ça représentait une collectivité qui request le QF d'un particulier.

C'est intéressant parce que sur ce site il n'est nullement question d'un usager de type collectivité 🤔

[skelz0r]

Techniquement c'est plus complet qu'un transfert, parce qu'on récupère un jeton FC, on tape sur API Particulier avec ce jeton, et on le stock sur HubEE.

DataTransfer c'est trop générique (et fondamentalement n'importe quel call API fait un transfert de données).
QuotientFamilialShipment c'est intéressant

J'avais proposé QuotientFamilialRequest mais en effet je suis pas vraiment convaincu (mais c'est mieux que claim imo)

[JeSuisUnCaillou]

C'est intéressant parce que sur ce site il n'est nullement question d'un usager de type collectivité 🤔

Ouais, mais comme un usager particulier ne fait pas vraiment une "demande de QF", mais plutôt un envoi, mon cerveau a compris que ça devait donc représenter la "demande" (request) d'une collectivité d'une manière ou d'une autre, même sans être un user du site.

[JeSuisUnCaillou]

J'aime bien aussi le QuotientFamilialShipment par ce que ça représente un truc un peu physique, genre c'est un containeur sur un bateau. Avec un QF et d'autres truc dedans. Et il va livrer sa cargaison au port de Hubee 🤣

[skelz0r]

QuotientFamilialApplication qui traduit la "demande" comme request sans le côté ambigue.

Ouais, mais comme un usager particulier ne fait pas vraiment une "demande de QF", mais plutôt un envoi

Il faut les 2 en fait mais bon.. in-fine c'est pour transférer à la collectivité.

[JeSuisUnCaillou]

QuotientFamilialShipment > QuotientFamilialApplication je trouve.
J'ai pas de justification, juste le feeling est mieux pour moi :)

[JeSuisUnCaillou]

Je propose QuotientFamilialShipment, voilà. Sinon rien d'autre à dire.

[skelz0r]

Je vous laisse trancher vu que c'est vous qui avez la tête dans le projet

[Un3x]

Bon je vois qu'il y a débat alors je me permet de mettre mon grain de sel (mais pratiquement on s'en fout).

Concrètement les données intéressantes dans le formulaire QF ben c'est pas vraiment le QF. Certes on le fournis dans le "package" des données stockées mais ca c'est de la récupération oneshot.
Les données qui sont "vraiment" intéressante sont les données de l'identitée pivot qui vont accompagner le QF et qui vont permettre aux éditeurs / communes / whatever de stocker ces données pour solliciter nos apis de facon autonome sans avoir à passer par hubee (qui ne fait pas de mise à jour de la donnée).

J'ai pas d'avis voilà

[jbfeldis]

C'est un bon débat, le naming c'est tellement pénible.

J'en rajoute une couche (histoire que le 3e renommage soit le bon).

Le FormulaireQF c'est très orienté "usager", donc le wording c'est plutôt "demande". J'arrive sur le site et je demande au système de fournir mon QF (et mon identité pivot mais pour l'usager c'est un détail) à ma commune.
Mais ce n'est pas si simple parce que, dans le cadre d'une mise à jour automatique du QF dans les petites communes, l'usager ne sera pas directement à l'initiative de chaque demande.
Donc si je reviens sur le site sur une hypothétique page "Mon Compte" comment s'appelle la liste des appels qui ont été faits avec mon identité pivot ?

Cela dit Shipment c'est visuel et agréable je trouve 🤷

(my 2 cents de reste de cerveau du vendredi)

On décide lundi matin !

[Un3x]

Les mises à jour automatiques ne se feront pas au travers de FQF si ?

C'est les FS qui vont récupérer les données sur Hubee, les stocker et après faire leurs appels (de ce que j'en ai compris), au quel cas, c'est bien un Transfer ou Shipment ou ExploitationAuthorization ou Storage (au fond c'est ca mais c'est pas très représentatif je trouve).

[jbfeldis]

L'idée c'est d'avoir 2 cas :

• les communes "équipées" (cad qui ont un éditeur ou un service tech avancé) : pour celles là, en effet, elles recup l'identité pivot et se débrouillent ensuite pour la mise à jour
• les "petites" communes : là on veut proposer la mise à jour qu'on gèrerait nous-même (avec cette fonctionnalité le service les intéresse beaucoup, sans ça... aucune utilité pour elles a priori)

[skelz0r]

C'est les FS qui vont récupérer les données sur Hubee, les stocker et après faire leurs appels

Dans le cas des petites communes on fait office de FS, la logique est la même imo, l'objet manipuler sera toujours le même, et je pense que shipment marche bien.

[JeSuisUnCaillou]

ça peut être DataShipment ou UserDataShipment si on veut se décorreller du QF

[JeSuisUnCaillou]

Je reviens pour dire que Shipment tout court, c'est vraiment bien aussi avec le recul et quelques essais de mon côté :)

[JeSuisUnCaillou]

let's go 🚀