Produits Entr'ouvert » Publik

Je propose de plutôt lier des comptes à des fiches (i.e. de stocker ça dans le profil).

Après les discussions de cette semaine, il s'agirait plutôt de lier les utilisateurs à des fiches dans le sens où ce serait les fiches qui pointeraient sur les utilisateurs.

Le fait de faire porter sur le profil du user l'identifiant de la fiche repose sur le passage au formulaire de création de fiche de l'uuid du user dans session_var : {{ eservices_url }}backoffice/data/{{fiche}}/add/?session_var_dossier={{json.uuid}}). Or L'usage des variables de session pose problème. Ce pourrait être fait en utilisant request.GET + préremplissage d'un champs. Mais la possibilité de lecture seule sur ce champs pourrait ne pas avoir le comportement attendu et laisser ce champs éditable pose propblème.

Ce développement devrait permettre de passer l'uuid du user à la fiche et ainsi assurer un comportement plus robuste, par exemple :

{{ eservices_url }}backoffice/data/{{fiche}}/add/?user-id={{json.uuid}}

• la barre latérale sur la fiche affichera le display name du user comme sur une demande,
• la possibilité de développer, conjointement aux vues personnalisées, des possibilités de vues pour les listings ou d'exports des fiches avec des données utilisateurs.

Afin de pouvoir accéder à la fiche associée à un utilisateur lorsque l'on dispose de l'uuid de l'utilisateur, comme par exemple suite à une recherche avec la cellule de recherche, la fiche pourra être recherché avec un appel API du type :

wcs/api/cards/whatever?filter-user-uuid={{user_nameid}}

Ce développement devrait permettre de passer l'uuid du user à la fiche et ainsi assurer un comportement plus robuste, par exemple :

{{ eservices_url }}backoffice/data/{{fiche}}/add/?user-id={{json.uuid}}

Je viens de tester et c'est déjà possible, comme pour les demandes, .../add/?NameID={{...}}.

Mis en place ce qui permet de se passer de session_var / request.GET.

Il reste donc wcs/api/cards/whatever?filter-user-uuid={{user_nameid}} pour pouvoir se passer du stockage de l'ID de la fiche sur le user.

Je le note ici pour mémoire et éviter une confusion, l'API sur les fiches prend déjà un paramètre NameID. Mais ce paramètre sert à l'autorisation et désigne l'utilisateur backoffice. Par exemple

{{ eservices_url }}api/cards/{{ fiche_slug }}/{{ fiche_id }}/?NameID={{ user_nameid }}

D'où en plus un paramètre sur GET {{ eservices_url }}api/cards/{{ fiche_slug }}/?filter-user-uuid

Suite aux tests avec #40050 j'obtiens cette définition de cellule :

    "seniors-fiche": {
      "name": "Seniors - Fiche",
      "url": "{{ idp_url }}api/users/{{ name_id }}",
      "form": [
        {"label": "Identifiant de la fiche", "varname": "fiche", "required": true}
      ],
      "varnames": [],
      "log_errors": false,
      "cache_duration": 0,
      "force_async": true,
      "additional-data": [
        {
          "key": "json_liste_fiches",
          "url": "{{ eservices_url }}api/cards/{{ fiche }}/list?NameID={{ user_nameid }}&filter-user-uuid={{ name_id }}",
          "cache_duration": 0,
          "log_errors": false,
          "timeout": 5
        },
        {
          "key": "json_fiche",
          "url": "{{ eservices_url }}api/cards/{{ fiche }}/{{ json_liste_fiches.data.0.id }}/?NameID={{ user_nameid }}",
          "cache_duration": 0,
          "log_errors": false,
          "timeout": 5
        }
      ]
    },

Est-ce correct pour ce cas où je n'ai qu'une fiche par utilisateur ?

Comment faire s'il y a plusieurs fiches associées à un utilisateur ?

Il est sûrement préférable de passer par une vue perso avec toutes les données souhaitées et de se contenter de l'appel sur /list.

Dans les 2 cas.

Je ne suis pas sûr d'avoir compris la question; l'endpoint /list renvoie dans tous les cas une liste.

Oui mais list ne renvoie pas toutes les données de la fiche, par exemple :

{'data': [{'digest': None,
           'display_id': '2-24',
           'display_name': 'Senior - n°2-24',
           'id': 24,
           'last_update_time': '2020-04-09T08:41:40',
           'receipt_time': '2020-02-20T10:43:44',
           'text': 'Senior - n°2-24',
           'url': '...backoffice/data/senior/24/'}]}

C'est pour cela que je chaîne un appel sur la fiche pour avoir les "fields".

Et il me semble plutôt préférable de faire renvoyer tous les fields directement via le premier (et unique) appel en utilisant une vue perso où serait configuré toutes les colonnes.

C'est comme pour les demandes, si tu veux tout tu peux faire ?full=on.

J'avais en tête ?all=on et ça ne marchait pas bien sûr, d'où la suite, merci.

Tu verrais ce ticket chapeauter d'autres devs comme #40031 par exemple ? Ou c'est tout autre chose ?

Aujourd'hui tu fais la liaison entre un utilisateur et une fiche en initiant la saisie depuis combo; ça fait deux points qui ne devraient pour moi pas être obligatoire : 1/ que ça soit uniquement à la saisie, et 2/ que ça soit uniquement via un lien posé dans combo.