Various fixes - "Devis" Generation is now available

[KiDayz]

Medium fixes

• Front-end change allowing the user to link an "etude" to a "facture" when creating or modifying a facture
• Front-end change allowing the user to generate a "devis" in "suivi d'étude/Etude 1/Rédaction et génération" in the Convention d'Etude tab

Minor fixes

• PVI becomes PVRI (as normally used)
• PVR becomes PVRF (as normally used) Please note that these changes only affect the front-end, there are no changes in the back-end (PVRI are stilled called by pvi variables - same for PVRF with pvr variables)

• When a "avenant" was created, it was called "PVI" in the "suivi" tab. Now it is called "AVCE" (= Avenant à la Convention d'Etude) as it should be

  Changes made by T.W. from Junior UTC

[Stoakes]

Merci beaucoup pour cette contribution.

Il y a beaucoup de choses bien donc elle sera probablement mergée, une fois la CI verte & les commentaires corrigés (git rebase -i c'est la vie).

Par contre, je ne suis pas fan des 2 commits

• Front-end change : PVI becomes PVRI
• Front-End change - "PVR" becomes "PVRF" *

Voilà ce que j'ai en tête à leur sujet: (cette liste est là pour ouvrir la discussion, pas pour chercher à détruire ces commits)

• Ces commits, génèrent beaucoup de changement.
• Les modifications ne toucheraient qu'aux traductions et aux templates ça irait à peu près, mais là on a des modifications plus profondes.
• Les nouvelles appellations sont-elle universellement partagée par toute les Juniors ? Renommer ces documents est-il bénéfique à la communauté Jeyser ? Que faire si demain une autre Junior vient proposer un revert de la modification car elle les appelle PVI & PVF ?
• Je ne suis plus capable d'évaluer l'impact de ces changements, donc je vais prendre doubles précautions avant de les merger.
• Est-ce important de renommer Proces Verbal Intermédiaire en Proces Verbal de Reception Intermédiaire et Proces Verbal Final en Proces Verbal de Reception Final ? Ou peut-on se contenter de l'appellation historique ?

A part ça, GG

[KiDayz]

Hello,

Merci pour tes corrections, je m'occuppe de regarder ça. Par contre je n'ai jamais utilisé git rebase, peux-tu m'expliquer rapidement pourquoi je devrais l'utiliser ? :)

C'est pour éviter de faire un commit sur ma branche avec les changes puis de refaire une PR ?

---

PVRI / PVRF

Merci pour tes commentaires et ton ouverture d'esprit, voilà ce que je peux apporter à la discussion :

• tu dis que ces commits genèrent beaucoup de changement profonds : peux-tu détailler ? C'est peut-être par manque d'expérience sur Jeyser, mais j'ai l'impression de n'avoir modifier que le côté front-end car seul l'affichage de l'objet PVI en tant que PVRI et PVR en tant que PVRF a été modifié à mon sens. En back, les boucles tournent toujours avec pvis et pvr , et les attributs au niveau de la génération de doc restent etude.pvr.dateSignature par exemple.
• Les nouvelles appellations devraient être utilisés par toutes les juniors (c'est mon côté Auditeur-Conseil qui parle ^^) car c'est l'unique appellation utilisée sur Kiwi Legal, cf les photos ci-après. Attention, le R dans PVR signifie Recette et non Réception.
• Je ne vois aucun intérêt à proposer un revert vers PVI/PVF pusique ces appellations n'existent pas (ou plus) du point de vue de la CNJE (cf les photos du Kiwi Legal). Je reste bien entendu ouvert aux contre-propositions sur cet avis. Donc pour répondre à ta question, si une autre Junior propose un revert, à mon avis il faudrait le refuser car ce ne sont plus des appellations à jour.
• Nous trouvions ce changement important car le turn-over en Junior est important (donc beaucoup de nouveaux) et une appellation différente des ressources documentaires proposées par Kiwi Légal et la CNJE en général me paraît déconcertant lorsque l'on utilise l'ERP. Pour te donner un exemple, cela fait bientôt trois ans que je suis en Junior, et je n'avais jamais entendu les appelations PVI et PVR.

[Stoakes]

PVR Ok, faisons comme ça.

git rebase -i est une commande git qui permet de re-écrire ton historique de commit. C'est particulièrement utile pour maintenir une liste de commit cohérente (et éviter les commits à la Address review comment ou encore Lint code).

Au lieu d'ajouter de nouveaux commits avec les modifications liées à la review, git rebase -i te permet de modifier les commits précédents, puis de les repousser (il faudra faire un git push --force pour forcer la ré-ecriture de l'historique).

Cet article explique plus en détails: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History (la partie "The Nuclear Option: filter-branch" et ce qui suit est moins utile).

Est ce que c'est bon ou tu souhaites plus de détails sur comment l'utiliser dans le cas de cette PR ?

[KiDayz]

Ok super merci pour l'explication, j'ai mis un peu de temps à tout comprendre et tout faire pour la première fois, mais ça devrait être bon. (le lien et tes explications étaient super utiles merci !)

[KiDayz]

@Stoakes Bon les checks sont passés, j'ai rebase pour n'avoir plus que les 6 commits existants, j'espère ne pas avoir oublié l'une de tes remarques mais je ne crois pas ^^ on y arrive doucement

[KiDayz]

j'ai ajouté les modifs que j'ai fais ce soir sur les graphs. J'espère que ça ne perturbe pas le process de review de la PR ?

[Stoakes]

On y est presque. Il ne reste plus que le && à la place du and et ca sera mergé.