ETQ usager, je peux déposer un dossier même si la vérification du Siret est temporairement indisponible#13255
Closed
E-L-T wants to merge 9 commits into
Closed
ETQ usager, je peux déposer un dossier même si la vérification du Siret est temporairement indisponible#13255E-L-T wants to merge 9 commits into
E-L-T wants to merge 9 commits into
Conversation
E-L-T
force-pushed
the
feat/dossier-submission-with-external-data-pending
branch
6 times, most recently
from
June 9, 2026 08:56
9f15161 to
d857c85
Compare
E-L-T
changed the title
E-L-T
force-pushed
the
feat/dossier-submission-with-external-data-pending
branch
from
June 9, 2026 09:12
d857c85 to
b0d7f5d
Compare
E-L-T
force-pushed
the
feat/dossier-submission-with-external-data-pending
branch
10 times, most recently
from
July 3, 2026 08:49
6e3394d to
dd8b3d2
Compare
Required to distinguish :not_found (business error) from :technical_error (API down / 5xx) when deciding whether to block dossier submission. kind: defaults to nil so existing call sites for other champs (RNA, RNF, Référentiel, quotient familial) keep working unchanged.
Returns false by default. Will be overridden later when a procedure has a logic condition that depends on a champ's value_json (SIRET/RNA/RNF).
…technical_error API Entreprise not_found (code 404) is the only blocking case. Degraded mode and other technical errors are now classified as :technical_error so the validator can let the user submit anyway.
…idate_etablissement validate_etablissement predates the kind/lenient rework and blocked on any missing etablissement regardless of kind, defeating the point of #12997 for external_error states: a technical_error still got a blocking :not_found error on external_id, independently of ExternalDataChampValidator's lenient logic. Skip this validation on external_error too (already skipped on pending): blocking on external_error is now exclusively ExternalDataChampValidator's job, which is kind-aware. Also fixed two specs that asserted `be_valid` after an explicit validate(:champs_public_value): be_valid re-triggers validation with no context, which should_validate_in_current_context? always rejects, silently no-oping the assertion. Assert on the already-populated errors instead.
…ed etablissement champ_blank_or_invalid? checked Siret.new(siret: champ.value), but value is only populated by a successful fetch (update_external_data!). For a mandatory SIRET champ, this meant the dossier's mandatory-field check (Dossier#check_mandatory_and_visible_champs_for) always blocked submission while pending or in a non-blocking technical_error, regardless of ExternalDataChampValidator's kind-aware logic. Check external_id's format instead: it's set as soon as the user types a SIRET and survives resets, so a mandatory field is satisfied by a syntactically valid input. Whether that SIRET actually exists is ExternalDataChampValidator's separate, kind-aware concern.
For a SIRET champ, the non-blocking technical_error banner (added below the input) and this component's own external_error warning were both rendered at once, contradicting each other visually (blue info + red warning for the same non-blocking state). The warning branch is unreachable for :not_found (validation errors take precedence in the template) and now redundant for :technical_error, so it's removed along with its now-unused translations.
E-L-T
force-pushed
the
feat/dossier-submission-with-external-data-pending
branch
from
July 6, 2026 13:55
dd8b3d2 to
c359186
Compare
Contributor
Author
|
fermé au profit d'une approche sans nouveau champ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ref #12997
Contexte
Aujourd'hui, si l'API Entreprise est en mode dégradé ou renvoie une erreur technique au moment de la vérification du SIRET, l'usager ne peut pas déposer son dossier.
Ce que fait cette PR
:not_found(SIRET inexistant, bloquant) et:technical_error(API indisponible, non bloquant)fr-info-text) sous le champ quand la vérification est en cours ou temporairement indisponiblePérimètre
Uniquement SiretChamp. Les autres champs avec données externes (RNF, RNA, référentiel…) seront traités dans des PRs à venir.
Points d'attention pour la revue
kind(requis). Les exceptions legacy en base désérialisent avec kind: nil, traité comme non-bloquant dans le validateur.handle_resultdansChampExternalDataConcerngarde des fallbacks sanskindpour les services pas encore migrés.lenient_external_data_validation?permet à un champ d'opter pour le comportement non-bloquant — seul SiretChamp l'active pour l'instant.