Produits Entr'ouvert » Passerelle

Lors des changements à la page en question, attention à bien inclure un commentaire décrivant le changement, pour faciliter le suivi.

certificate_type: AEC (acte etat civil), RCO (recensement citoyen obligatoire), ILE (inscription sur les listes electorales)
document_type: Copie integrale, Extrait avec Filiation, Extrait sans filiation, etc.

Bizarre d'avoir pour les types de certificats des "codes" et pour les types de document des libellés.

document_copies: Nombre d'exemplaire

Quand le type de données n'est pas une chaine de caractère, le préciser.

applicant_is_concerned (dit si le demandeur est aussi la personne concernée par la demande)

Pourquoi a-t-on besoin de cette information plutôt que la déduire de applicant_...name vs concerned_...name.

concerned_sexe

sex

address_street_no

Pour "concerned_birthcountry" par exemple, on n'a pas d'underscore pour séparer les mots. address_streetno du coup.

address_complement

Il faut noter les champs qui sont facultatifs.

<individu>_title

Il faut décrire le contenu attendu, l'exemple qui suit contient "partner_title": "Madame" et "partner_title_raw": "M".

<individu>_sexe

sex

"concerned_address_stree": "27 Blvd Henry Orion",

Erreur dans l'attribut.

"concerned_parent2_firstnames": "Kim",

L'exemple contient un seul parent, dans parent2, est-ce considéré ok ?

Aussi, le remplacement de père/mère par parent1 et parent2 est ma suggestion mais quelqu'un aurait pu noter que les fichiers qui doivent être produits pour MDEL parlent de Pere/Mere. Cela veut peut-être dire qu'on doit également exiger un concerned_parent2_sex ?

Le retour attendu est un json contenant la clé demand_id i.e. :

Plutôt retourner un dictionnaire avec les clés data et err, définir que err contient 0 en situation de succès, et que dans data alors il y a une clé demand_id.

La réponse renvoyée doit au minimum avoir les clés status et closed (Boolean).

Même remarque, data et err.

Sources de données

Quelles sont-elles ?

Lors des changements à la page en question, attention à bien inclure un commentaire décrivant le changement, pour faciliter le suivi.

Frédéric Péters a écrit :

certificate_type: AEC (acte etat civil), RCO (recensement citoyen obligatoire), ILE (inscription sur les listes electorales)
document_type: Copie integrale, Extrait avec Filiation, Extrait sans filiation, etc.

Bizarre d'avoir pour les types de certificats des "codes" et pour les types de document des libellés.

Une scorie de début d'édition.

document_copies: Nombre d'exemplaire

Quand le type de données n'est pas une chaine de caractère, le préciser.

J'ai mis à jour la doc, les types sont indiqués

applicant_is_concerned (dit si le demandeur est aussi la personne concernée par la demande)

Pourquoi a-t-on besoin de cette information plutôt que la déduire de applicant_...name vs concerned_...name.

J'étais encore sur l'idée que le formdata envoyé au connecteur n'était pas explicitement construit

concerned_sexe

sex

Corrigé

address_street_no

Pour "concerned_birthcountry" par exemple, on n'a pas d'underscore pour séparer les mots. address_streetno du coup.

Corrigé dans la doc

address_complement

Il faut noter les champs qui sont facultatifs.

Ajouté dans la nouvelle version de la documentation

<individu>_title

Il faut décrire le contenu attendu, l'exemple qui suit contient "partner_title": "Madame" et "partner_title_raw": "M".

<individu>_sexe

sex

"concerned_address_stree": "27 Blvd Henry Orion",

Erreur dans l'attribut.

"concerned_parent2_firstnames": "Kim",

L'exemple contient un seul parent, dans parent2, est-ce considéré ok ?

Oui, parce que les variables relatives aux parents sont facultatives.

Aussi, le remplacement de père/mère par parent1 et parent2 est ma suggestion mais quelqu'un aurait pu noter que les fichiers qui doivent être produits pour MDEL parlent de Pere/Mere. Cela veut peut-être dire qu'on doit également exiger un concerned_parent2_sex ?

Oui on peut ajouter cette variable.

Le retour attendu est un json contenant la clé demand_id i.e. :

Plutôt retourner un dictionnaire avec les clés data et err, définir que err contient 0 en situation de succès, et que dans data alors il y a une clé demand_id.

Remarque prise en compte dans la doc.

La réponse renvoyée doit au minimum avoir les clés status et closed (Boolean).

Même remarque, data et err.

Sources de données

Quelles sont-elles ?

• title
• sex
• certificate_type
• document_type
• applicant_status

Les valeurs attendues changent en fonction du connecteur.

Pour les champs fermés, préciser les valeurs autorisées; cela permettra aussi de constituer la liste exhaustive des sources de données.

Pour les dates, préciser que c'est de champ date plutôt que taper l'info en commentaire.

Les champs concerned_title et concerned_sex me paraissent redondants. Pareil pour partner. Un seul suffit, non?

Serghei Mihai a écrit :

Les champs concerned_title et concerned_sex me paraissent redondants. Pareil pour partner. Un seul suffit, non?

Oui on peut se contenter de _sex et en déduire le _title, mais je pense que le plus simple c'est de fournir l'information quand elle existe au lieu de traiter une condition au niveau du connecteur.

Au cas où, j'ai pas été voir sur MDEL, mais le sexe et le titre sont deux choses distinctes en France. Pour le titre, pour un avocat un notaire ou un huisser ça pourra être "Maître". Y'a aussi "Professeur", "Docteur", etc... Faut voir comment sont faits les formulaires AEC sur MDEL, j'ai pas ce courage ;)

Thomas Noël a écrit :

Au cas où, j'ai pas été voir sur MDEL, mais le sexe et le titre sont deux choses distinctes en France. Pour le titre, pour un avocat un notaire ou un huisser ça pourra être "Maître". Y'a aussi "Professeur", "Docteur", etc... Faut voir comment sont faits les formulaires AEC sur MDEL, j'ai pas ce courage ;)

Yep vrai, vu que le demandeur peut etre un représentant légal.
(Par rapport à MDEL, title est identifié par la balise civilité ayant 2 valeurs possible: MONSIEUR ou MADAME)

Utilisation de father et mother à la place de parent1 et parent2

Discutons des modifications ici plutôt que les faire dans le wiki.

Le choix d'utiliser parent1 et parent2 était conscient, tu ne peux pas annuler ça sans discussion.

Frédéric Péters a écrit :

Utilisation de father et mother à la place de parent1 et parent2

Discutons des modifications ici plutôt que les faire dans le wiki.

Le choix d'utiliser parent1 et parent2 était conscient, tu ne peux pas annuler ça sans discussion.

• garder parent1 et parent2 et dire dans la spec que parent1 = pere et parent2 = mere.
• utiliser father et mother et dire que les applications derrière ne gèrent pas les cas des parents de meme sexe.

garder parent1 et parent2 et dire dans la spec que parent1 = pere et parent2 = mere.

garder parent1 et parent2 et regarder l'info parentN_sex posée à côté pour les applications derrière qui exigeraient ça.

Ce qui était l'idée, il y a un bail, moi puis toi :

Aussi, le remplacement de père/mère par parent1 et parent2 est ma suggestion mais quelqu'un aurait pu noter que les fichiers qui doivent être produits pour MDEL parlent de Pere/Mere. Cela veut peut-être dire qu'on doit également exiger un concerned_parent2_sex ?

Oui on peut ajouter cette variable.

→ L'attribut _sex a été ajouté explicitement pour cette situation.