Produits Entr'ouvert » Fargo

• depuis un formulaire w.c.s.: on obtient un lien directement (dans fargo) vers un document particulier d'un utilisateur particulier, un premier formulaire donne le choix d'un type, puis un second demande les détails, si possible en conservant le document visible tout du long (visionneuse),
• depuis l'accueil de la mairie (welco ?): on recherche/crée un utilisateur, on choisit l'action valider un justificatif, on est amené sur fargo (ou l'utilisateur créé dans authentic aura du être propagé), où on peut créer sans document (puisqu'il n'est pas stocké) un document justificatif et les données associées.

Coté modèle de donnée pour chaque document on associe un type, nom, prénom, email et uuid du valideur, ainsi qu'une liste d'attributs (clé-valeur). Le schéma des types de document est défini dans les settings.

Les fichiers sont stockés de manière unique indexé par le SHA256 dans le modèle Document.

Le modèle UserDocument relie un document à un utilisateur.

Le modèle Validation stocke la validation d'un document relié à un utilisateur pour un certain type.

• un web service qui distribue simplement la liste des types de documents pour éviter d'avoir à la répliquer partout, dans les faits ça publie simplement {'err': 0, 'data': settings.FARGO_DOCUMENT_TYPES }
• un web service de publication des métadonnées associé à un triplet <name_id ou username>/<condensat sha-256 du fichier>/<slug du type de document> qui renvoie 404 si aucune fichier n'est trouvé, {'err': 1, data: 'validation not found'} si le fichier existe mais ils n'existent pas de métadonnées validées pour ce type de fichier, ou enfin les métadonnées sous la forme:
  

  {
     "err" : 0,
     "data" : {
        "type" : "justificatif-de-domicile",
        "created" : "2015-09-28T08:43:11Z",
        "end" : "2015-09-17",
        "start" : "2015-09-01",
        "label" : "Justificatif de domicile",
        "metadata" : [
           {
              "name" : "numero",
              "label" : "Numéro",
              "value" : "23" 
           },
           {
              "value" : "rue du château",
              "name" : "rue",
              "label" : "Rue" 
           },
           {
              "name" : "code-postal",
              "label" : "Code postal",
              "value" : "75014" 
           },
           {
              "name" : "ville",
              "label" : "Ville",
              "value" : "PARIS" 
           }
        ],
        "creator" : "Benjamin Dauvergne" 
     }
  }
  

• une page de validation qui accepte le même triplet et affiche un formulaire pour remplir les métadonnées en question, elle accepte en plus un paramètre next pour le retour sur l'application d'origine (un jour on pourra tenter un window.postMessage pour fermer les iframe en popup mais j'ai eu la flemme là.

• déterminer une règle d'autorisation concernant la possibilité d'utiliser la page de validation, je serai d'avis d'associer cela à des rôles, ceux propagés par authentic2 dans fargo, le backoffice de celui-ci offrant la possibilité d'associer des rôles à des types; le message d'erreur du web service des métadonnées pourra envoyer les uuid de ces rôles permettant à w.c.s de savoir s'il doit afficher le lien de validation ou pas
• permettre de pousser dans fargo un fichier qui n'y est pas en même temps qu'on le valide, cela supprimera le retour 404 actuellement renvoyé dans ce cas.

Je vais poster en parallèle le patch pour w.c.s.

Ok mon virtualenv fargo était obsolète. J'ai mis à jour et c'est bon.

Les codes paths SAML ne sont pas testés, j'ai corrigé la ligne.

Pour les boutons valider oui c'est du debug, à virer quant tout le reste est ok.

Ok, variante avec uniquement user__username=username[:30].

Pour le 404:

diff --git a/fargo/fargo/views.py b/fargo/fargo/views.py
index 764a7de..1c0a1a4 100644
--- a/fargo/fargo/views.py
+++ b/fargo/fargo/views.py
@@ -316,7 +316,8 @@ class Validation(CreateView):
         return kwargs

     def get_success_url(self):
-        return self.request.GET.get(REDIRECT_FIELD_NAME) or settings.LOGIN_REDIRECT_URL
+        return self.request.GET.get(REDIRECT_FIELD_NAME) \
+                or reverse(settings.LOGIN_REDIRECT_URL)

 class DocumentTypes(View):

(patch complet attaché)

Pour les champs requis je viens d'ajouter la possibilité de mettre un 'required': False dans le schéma (par défaut c'est True).

Appliqué par commit f166d3fbe3a3e5911c04076f45747220bd90d986.