Produits Entr'ouvert » Passerelle

Clairement tu veux un panneau backoffice ?

J'imaginais plutôt une suggestion de FOOBAR_ENABLE, comme tu as dans Authentic. (i.e. avoir des settings.json, pas des settings.py) Mais je laisse Thomas dire.

Benjamin Dauvergne a écrit :

Clairement tu veux un panneau backoffice ?

Nope, PASSERELLE_APPS défini justement les applications (types de connecteurs) qu'on veut rendre accessibles sur un tenant donné, et pas sur les autres. Par exemple "agoraplus" seulement pour les clients qui en ont l'utilité.

(C'est pas très grave, dans les déploiements actuels on peut considérer qu'on met toutes les applis dans PASSERELLE_APPS et voilà, mais bon, ça va finir par faire des /manage plein de trucs inutiles)

Frédéric Péters a écrit :

J'imaginais plutôt une suggestion de FOOBAR_ENABLE, comme tu as dans Authentic. (i.e. avoir des settings.json, pas des settings.py) Mais je laisse Thomas dire.

Ouaip, ça pourrait être une façon de faire plus rusée que le trop générique PASSERELLE_APPS. Il faut j'imagine ajouter une méthode de classe "is_enabled" par ressource (True par défaut) ?

Ça où avoir une rèlgle pour des variables du PASSERELLE_APP_<APP_NAME>_ENABLED et faire une méthode is_enabled() générique dans la classe de base (s'il y en a une).

On pourrait totalement supprimer le PASSERELLE_APPS, non ?

Frédéric Péters a écrit :

On pourrait totalement supprimer le PASSERELLE_APPS, non ?

Oui, c'est suffisamment peu utilisé, voire pas, c'est donc le bon moment.
Et dans ce cas il faut mettre des PASSERELLE_APP_TRUC_ENABLED par défaut. Je regarde ça.

Il faudrait déclarer les applications de contrib dans INSTALLED_APPS, non?

Non, le contrib c'est ce qu'on ne veut vraiment pas installé par défaut; pas même les modèles, rien.

Oui, pour les contrib on a un README dans chacun, qui explique entre autre comment l'activer.

Je ne vois pas actuellement comment activer une contrib pour un client et pas pour un autre en production ou test (en dév ça va). Pour le futur, et maintenant que les settings sont chargés par rapport à connection.tenant et plus via request.tenant il semblerait possible via un SettingsLoader de modifier TENANT_APPS par 'tenant', ça nécessite quand même de tout déclarer dans INSTALLED_APPS, migrate_schemas faisant une comparaison entre les deux pour savoir ce qu'il faut migrer ou pas (le migrate de base se base uniquement sur INSTALLED_APPS, ensuite django-tenant-schemas rajoute un hook 'allow_migration' qui répond non si l'application en question n'est pas dans TENANT_APPS).

• on le pose dans le INSTALLED_APPS général
• on l'active via un PASSERELLE_APPS_TRUC_ENABLED=True dans le tenant
  Et voilà.

Mais par défaut, on ne place pas toutes les contrib dans INSTALLED_APPS, c'est à nous de le faire sur notre SaaS.

Yep je sais mais les modèles sont quand même créés pour tout le monde (ce qui n'est pas bien gênant).

Benjamin Dauvergne a écrit :

Yep je sais mais les modèles sont quand même créés pour tout le monde (ce qui n'est pas bien gênant).

Oui, je sais, mais j'ai pensé que si on veut ne pas activer les modèles, je pense qu'on risque de bidouiller un peu trop django-tenants. Je pense qu'il faut éviter de jouer avec les settings dans nos TenantSettings, i.e. se cantonner à ceux qu'on maîtrise bien.

Et donc, ouaip, je préfère rester dans un mode "normal" : toutes les applications chez tout le monde, mais seulement certaines visibles et exploitables, via des "activations". On le fait déjà dans combo, on le fait déjà dans Passerelle (PASSERELLE_APPS), ce patch est juste une autre façon de faire dans passerelle.

Voilà maintenant je veux bien un ack ;)

Oui oui ack. Je discutais juste de la remarque de Fred sur le fait de ne pas créer les modèles des applications dans contrib, ce qui ne me semble pas possible concernant les contrib utilisées, effectivement celles que personne n'utilise on peut aussi bien les enlever de passerelle.

Ack aussi