Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

La raison d'être des consentements est de savoir si on a le droit de faire tel ou tel traitement. Cette information peut être obtenue par plusieurs moyens décrits ici.

les snippets sont volontairement gardés au plus simple (pas de contrôle d’erreur, de gestion des sessions etc … ).

vous aurez besoin d’un environnement linux disposant de curl et jq pour faire fonctionner les exemples.

Contenu de cette documentation :

En exportant les consentements via l’API

Avec cette approche, on exporte au format json les consentements qui nous intéressent. Cette approche est intéressante si suivie d’une injection dans un ETL quelconque.

Export de la base au format json zippé

À l’issue de cette commande, le répertoire courant contiendra une archive ZIP contenant la base de vérité.

On utilise la route /organisations/{oid}/consents :

/usr/bin/curl --fail --silent \
  https://core.fairandsmart.com/api/organisations/MY_ORG/consents?limit=1000  \
  -H "accept: application/zip" \
  -H "authorization: Bearer ACCESS_TOKEN" \
  -o consents.zip

Se reporter à la documentation de l’API pour la liste des filtres disponible, pagination, etc …

Export de la base au format json avec filtrage local

À l’issue de cette commande, le répertoire courant contiendra un json avec la liste d’utilisateur ayant répondu OUI à la seconde finalité (id=1) du premier traitement (id=0) de mon modèle de consentement MY_MODELSERIAL.

On utilise la route /organisations/{oid}/consents :

/usr/bin/curl --fail --silent \
  https://core.fairandsmart.com/api/organisations/MY_ORG/consents?limit=1000&serial=${MY_MODELSERIAL}  \
  -H "accept: application/json" \
  -H "authorization: Bearer ACCESS_TOKEN" \
| /usr/bin/jq -c '.values[] | select( .value | contains("0-1"))' \
| /usr/bin/jq -c '{"userid": (.author)}' \
| /usr/bin/jq -s .    

Se reporter à la documentation de l’API pour la liste des filtres disponible, pagination, etc …

En interrogeant la base de vérité via l’API

Ici on demande si un utilisateur donné a consenti à un traitement donné. Cet appel ne fonctionne que si la finalité visée référence un traitement :

Les références de traitement associés peuvent être créés et positionnés pendant, mais également après activation d’un modèle.

On utilise la route /organisations/{oid}/treatments/query

/usr/bin/curl --fail --silent \
  https://core.fairandsmart.com/api/organisations/MY_ORG/treatments/query  \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -H "authorization: Bearer ACCESS_TOKEN" \
  --data-binary '{
    "organisationId":"MY_ORG",
    "treatmentKey":"MY_TREATMENT",
    "userId":"THE_USER_ID",
    "date":"",
    "attributes":{}
    }' \
| jq .evaluations[0].evaluation

A l’issue de la commande, on obtient “true” (→ traitement autorisé) ou “false ( → traitement non autorisé);

si le traitement est référencé depuis plusieurs modèles, c’est la réponse au dernier consentement collecté qui prime

le résultat sera “false” si l’utilisateur a renvoyé le formulaire avec une réponse négative, mais également s’il a révoqué son consentement ou s’il n’a jamais renvoyé le formulaire.

Se reporter à la documentation de l’API pour la définition du payload.

En exportant les consentements via l’interface

<à venir>

En interrogeant la base de vérité via l’interface

<à venir>

  • No labels