-
Notifications
You must be signed in to change notification settings - Fork 25
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
Limiter la suppression des SIAE inactives dans l’import ASP #4151
Conversation
Je ne sais pas s'il faut des tests en plus :) |
Group upcoming tests.
f89d473
to
1939dec
Compare
J’ai rajouté un test pour les candidatures. Pour les durées, c’est pénible, car le chemin de code demande des vues sur les CSV RIAE. Vu la difficulté à tester vs la complexité du changement, j’aurais bien tendance à mettre ça sous le tapis. |
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.
👍 pour le changement dans could_siae_be_deleted()
, beaucoup moins convaincu par l'augmentation de la durée :).
- Supprimer une SIAE sans convention et sans activité (c'est plus sur ça qu'on pèche) n'est pas grave, si elle devient conventionnée elle sera automatiquement recréée.
- Depuis l'ajout de la localisation aux fiches de poste, il n'est plus nécessaire pour les employeurs de créer des antennes pour être présent géographiquement.
- Les SIAE créées par le support c'est pour que l'employeur ne soit pas bloqué en attendant que le conventionnement passe entre chaque administrations, mais sans convention l'envoi des FS (:moneybag:) est de toute façon bloqué donc les employeurs vont assez rarement embaucher si ils n'ont pas la visu sur quand ils pourront toucher l'aide au poste.
Si la structure en question est juste une antenne mais avec quasiment pas de passage alors le changement de could_siae_be_deleted()
suffit, si elle est toujours en attente de conventionnement alors c'est sûrement dans les mains de la DDETS/DRETS et il y a sûrement des choses dont nous ne sommes pas au courant.
@@ -241,7 +241,7 @@ def manage_staff_created_siaes(): | |||
|
|||
If the siae cannot be deleted because it has data, a warning will be shown to supportix. | |||
""" | |||
three_months_ago = timezone.now() - timezone.timedelta(days=90) | |||
a_year_ago = timezone.now() - timezone.timedelta(days=365) |
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.
1 an me semble un peu trop, les AF étant signées chaque années pour [0-12] mois.
Il y a certes toujours du retard en début d'année mais historiquement au bout de 3 à 6 mois c'est à jour sauf cas particulier (souvent les DROM) donc je descendrais le compteur pour avoir l'alerte pas trop tard, surtout que les structures créés dans l'admin son celles en cours de conventionnement et pour qui on donne un passe droit donc c'est pas choquant de revisiter ce passe droit bien avant 1 an car entre temps il est possible que le conventionnement soit tombé à l'eau ou qu'il y ai un problème dans l'import comme c'est déjà arrivé.
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.
Mon inquiétude était qu’une structure qui a été créée pour un utilisateur, mais qui n’a pas de candidature, peut être supprimée “assez rapidement”.
Mon cas d’utilisation est un cas particulier, les EA n’ont pas la main pour créer des antennes et demandent au support de créer leurs antennes. Peut-être qu’il faudrait simplement les basculer en source=USER_CREATED
, même si le support fait l’action ?
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.
On peut aussi ne pas toucher à la durée ici, et seulement basculer sync_structures
à 1 an ?
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.
Pas la peine de trop se prendre la tête avec les EA/EATT, elles vont tendre vers ce qu'on fait pour les SIAE avec l'import des structures depuis les données de l'ASP, ou en tout cas on se reposera la question à ce moment là :).
Je ne vois pas d'impact négatif d'augmenter uniquement dans sync_structures()
vu que ce sont des imports plus "souple", ça nous fait même un petit ballon d'essai pour éventuellement ne plus les supprimer ;).
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.
Ça me va bien ! J’ai revert sur les SIAE et ajouté un commentaire sur les EA/EATT/GEIQ par rapport au délai vs les SIAE.
1939dec
to
c0da496
Compare
A user got her antenna deleted twice. In the second deletion, she received notification emails for an application, but the system deleted both the antenna and the related job applications. Let’s prevent deletions when there are job applications, to keep a record of events happening on the system. Also, the grace period before an SIAE is deleted has been extended to a year. That leaves more time for an antenna to become active. There’s little harm in keeping unused SIAE a while longer, but losing data is harmful.
c0da496
to
5d15870
Compare
🤔 Pourquoi ?
L’antenne crée pour une utilisatrice a été supprimée deux fois par l’import EA. Avant la seconde suppression, la structure avait reçu des candidatures, et l’utilisatrice avait reçu des emails de notification, mais la commande a supprimé à la fois la structure et les candidatures associées.
https://plateforme-inclusion.zendesk.com/agent/tickets/14669
🍰 Comment ?
Pour éviter que le problème ne se produise :