Produits Entr'ouvert » Authentic 2

J’ai poussé une branche, j’imagine que ça irait s’accompagner d’une page de gestion des types de profils ou d’une api à cet effet. Je vais d’abord me creuser la tête sur #58556 puis revenir sur ce présent ticket.

La branche à jour avec l’api de gestion des types de profil et les événements de journal.

On utilise le modèle générique authentic2.models.Service pour représenter cette limitation de types de profil à un ou plusieurs services.
Il reste la problématique de permission d’accès à l’API. Je n’ai pas encore regardé si l’usage d’une permission dédiée est nécessaire, je vais regarder cela.

Je commence la partie correspondante dans authentic2_idp_oidc, de logique d’authentification et de génération de la mire de login, telle que décrite dans #58556.

• 0003: je ne vois pas l'utilité de cette API à ce stade, une raison ?

J’imaginais le cas où notre modèle générique avec deux types "gestionnaire" et "mandataire" ne conviendrait pas, et donc l’appli Publik PM laisserait la possibilité à l’admin fonctionnel de gérer quels sont les profils acceptables, et ceci aussi via des fiches avec appels WS dans le WF de fiche (ce qui justifiait aussi 0002).

On peut décider que ce n’est pas ce que l’on veut, auquel cas on ne conserve que 0001.

Paul Marillonnet a écrit :

Paul Marillonnet a écrit :

• 0003: je ne vois pas l'utilité de cette API à ce stade, une raison ?

J’imaginais le cas où notre modèle générique avec deux types "gestionnaire" et "mandataire" ne conviendrait pas, et donc l’appli Publik PM laisserait la possibilité à l’admin fonctionnel de gérer quels sont les profils acceptables, et ceci aussi via des fiches avec appels WS dans le WF de fiche (ce qui justifiait aussi 0002).

On peut décider que ce n’est pas ce que l’on veut, auquel cas on ne conserve que 0001.

Bon, je laisse de côté pour l’instant 0002 et 0003.

Voici 0001 corrigé en tenant compte de tes remarques. Django n’aime pas les 2 M2M de part et d’autre (d’ailleurs je n’ai retrouvé aucun usage documenté à ce sujet), ici dans le patch il n’y en a qu’un seul, défini avec un related_name pour pouvoir y accéder depuis l’autre modèle.

Non il faut définir un troisième model :

class R:
  a = FK(A)
  b = FK(B)

class A:
  bs = M2M(to=B, through=R)

class B:
  bs = M2M(to=A, trough=R)

Benjamin Dauvergne a écrit :

Non il faut définir un troisième model :

[...]

Oui c’est précisément ce que j’avais fait, peut-être m’y étais-je mal pris parce que django n’avait pas l’air du tout de comprendre le modèle intermédiaire avec un M2M déclaré de part et d’autre.

Ok, il me manquait le run_before, bien vu.

Automatic expiration