Projet

Général

Profil

Development #6642

Webservices : Exposition de la liste exhaustive des demandes sous forme minimaliste

Ajouté par Victor Claudet il y a environ 9 ans. Mis à jour il y a plus de 8 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
09 mars 2015
Echéance:
23 mars 2015
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:

Description

Création d’un nouveau Webservice qui expose la liste exhaustive des demandes sous forme minimaliste


Fichiers

Révisions associées

Révision 588a5cb1 (diff)
Ajouté par Thomas Noël il y a environ 9 ans

add json listings in /api/forms/ (#6642)

Historique

#2

Mis à jour par Thomas Noël il y a environ 9 ans

Dans ce patch:
  • backoffice/<formdef>/json renvoie une liste très minimaliste, pour chaque demande : id, date d'envoi, date de dernière modification.
  • cette liste est un "export json", qui sait utiliser les mêmes filtres qu'un export csv ou ods (sauf pour les champs qui ne sont pas exportés dans cette liste)
  • cette liste est prévue pour une utilisation en première étape dans des scripts de synchro :
    • le script demande cette liste
    • il compare avec ce qu'il connait (l'autre base à synchroniser)
    • il demande ensuite un par un les export json des nouvelles demandes, ou il envoie ses nouveautés (via des triggers)
  • (note : j'ai factorisé le JSONEncoder dans qommon.misc, on peut en discuter)
Il manque:
  • obligatoire: la doc que j'imagine ajouter dans http://doc.entrouvert.org/wcs/dev/api-schema.html (je ne pousserai pas le patch sans, mais je veux bien une première lecture du code)
  • pour plus tard: ajouter un filtre sur les dates (receipt et last_update) permettant de ne renvoyer que les demandes récentes ou récemment modifiées (genre ?timedelta=... ou autre nom d'argument plus pertinent)
#3

Mis à jour par Frédéric Péters il y a environ 9 ans

Ok, ça doit plutôt être du bricolage d'exposer ça sous /api/.../, on va laisser cette partie pour plus tard. Cela étant quand même, j'incluerais l'url du formdata dans le dictionnaire, plutôt que de demander à l'appelant de construire par lui-même cette URL.

#4

Mis à jour par Thomas Noël il y a environ 9 ans

J'ai ajouté un get_url(backoffice=True). Le backoffice=True pour suivre la logique de ce webservice de listing backoffice.

Ceci étant, par rapport au /api : je me pose quand même tout d'un coup, bêtement, la question de l'accès au backoffice avec une URL signée (get_user_from_api)...

#5

Mis à jour par Frédéric Péters il y a environ 9 ans

Je viens de valider sur un début de test unitaire et ça ne va pas passer; de manière globale l'accès à /backoffice/ est bloqué ainsi :

        user = get_request().user
        if not user and get_publisher().user_class.count() > 0:
            raise errors.AccessUnauthorizedError(
                    public_msg = _('Access to backoffice is restricted to authorized persons only. '\
                                   'Please login.'))

On sait qu'on n'a pas envie de mélanger get_request().user et le get_user_from_api_query_string. À mon sens on se trouve ici finalement obligé d'aller vers le /api/; en y mettant un ApiFormPage héritant du FormPage de backoffice/root.py, avec un _q_export n'exposant que le json. On garderait donc le patch comme il est, ce sera toujours utile de pouvoir faire un /json de test depuis le backoffice; mais en parallèle on crée le ApiFormPage(FormPage) qu'on place sous /api/.

#6

Mis à jour par Thomas Noël il y a environ 9 ans

Ok. Je compte pousser le patch avec un message de commit différent :

    backoffice/listings: add minimal JSON export (#6642)

    also move JSONEncoder to qommon.misc

Ok ?

#7

Mis à jour par Frédéric Péters il y a environ 9 ans

(poussé ainsi)

#8

Mis à jour par Thomas Noël il y a environ 9 ans

Voilà un patch qui donne accès à la mini-liste json aussi depuis /api/forms/<formdef>/json

La fin /json de l'URL me chiffonne un peu, pas très explicite, surtout quand on va ajouter d'autres choses dans ce /api. Mais je propose de quand même pousser ainsi, je signale dans la doc que l'URL n'est pas définitive...

#9

Mis à jour par Thomas Noël il y a environ 9 ans

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Thomas Noël
  • Patch proposed changé de Non à Oui
#10

Mis à jour par Frédéric Péters il y a environ 9 ans

Vrac.

Si on a un peu de temps pour réfléchir à la structure d'URL, allons-y; j'éviterais le '/json', pourquoi pas /api/forms/<urlname>/list ?

Par ailleurs, les URL données pour les formdata sont des /backoffice/... qui ne seront pas accessibles (ajouter un paramètre api=False au get_url() des formdata ?) (ou simplement retirer le backoffice=True pour le moment ?).

Dans le init de FormPage, il y a une vérification de get_request().user, il me semble qu'il faut donc y mettre un init propre, ou factoriser un peu l'existant.

Et dans le _q_lookup de ApiFormsDirectory, je ne suis pas sûr du "or get_request().user", je limiterais aux utilisateurs spécifiques API (j'entends bien l'avantage pour le debug, donc peut-être prendre en considération get_request().user si celui-ci est admin ?).

#11

Mis à jour par Thomas Noël il y a environ 9 ans

Bien d'accord avec tout ça, voici un nouveau patch incluant ces remarques. Ça donne pas une grande impression de propreté, mais ça marche.

Je n'ai pas été jusqu'à mettre le api=False dans les get_url, pour ne pas trop impacter.

(dans ce patch, une idée en plus : j'ai forcé le "filter=all" pour cette liste, parce que ça sera le cas d'usage le plus probable)

#12

Mis à jour par Frédéric Péters il y a environ 9 ans

Ça m'a l'air ok (j'aurais mis le forms = ... au-dessus des méthodes de la classe); seul truc, ce n'était pas l'occasion d'écrire pour toi d'écrire des tests ?

#13

Mis à jour par Thomas Noël il y a environ 9 ans

  • Projet changé de Vincennes à w.c.s.
  • Statut changé de En cours à Résolu (à déployer)

Voilà, poussé.

#14

Mis à jour par Thomas Noël il y a plus de 8 ans

  • Statut changé de Résolu (à déployer) à Fermé

Formats disponibles : Atom PDF