Permettre aux agents de se créer un compte sans organisation via Proconnect

[victormours]

Closes #5060

Contexte

voir #5060

On a 3 objectifs :

• éviter les agents bloqués par une connexion au mauvais compte proconnect
• permettre la création de compte via proconnect pour ne pas bloquer l'oauth dans le cadre des intégrations
• expliquer aux agents qui cherchent à rejoindre une organisation comment faire

Solution

On autorise la création de comptes via proconnect, mais uniquement pour le domaine RDV Service Public.
On met à jour le formulaire d'ouverture de compte dans le super admin pour ajouter un agent (optionnel), et on permet de faire cette ouverture si un agent n'a pas d'organisation.

Dans la "state machine" des agents, c'est possible de ne pas avoir de compte dans l'état initial, mais pas dans un état intermédiaire ou final, parce que le compte de l'agent est supprimé s'il est retiré de toutes ses organisations.

L'agent créé ainsi n'a pas de service. On autorise l'ajout de services lorsque l'agent est créé par un super admin ou invité par un autre admin d'orga ou de territoire.

On va voir avec l'équipe déploiement comment on ajoute ces agents à leur crm.

Captures d'écran

Avant	Après

[victormours]

Texte :

Pour commencer, aidez-nous à reconnaître votre organisation.

Si vos collègues utilisent déjà RDV Solidarités, ils peuvent vous inviter dans leur espace via le menu “Paramètres > Agents > Ajouter un agent”.

Si vous souhaitez ouvrir un nouvel espace sur RDV Solidarités pour votre organisation, notre équipe est là vous aider.

[MatisAlves]

Texte :

Il semblerait qu’il y ait un problème.
Pour commencer, aidez-nous à en savoir plus :

• Votre structure utilise déjà RDV Service Public et vous souhaitez disposer d’un accès ?
  Seuls vos collègues utilisateurs peuvent vous inviter depuis le menu Paramètres > Agents > Ajouter un agent

• Votre structure n’utilise pas RDV Service Public et vous souhaitez créer un compte ?
  Nous vous invitons à contacter notre équipe. Nous organiserons un temps d’échanges pour vous présenter la solution et créer le compte de votre structure.

-> CTA « contacter notre équipe »

[francois-ferrandis]

C'est fou de faire tomber autant de certitudes en si peu de code ! 🤯

Je n'ai pas d'objection à merger comme ça. 🚀

[francois-ferrandis]

Je prédit que l'omelette ne se fera pas sans casser des œufs, mais moi aussi j'ai faim ! 😉

[francois-ferrandis]

Trop malin ! 🤩

[francois-ferrandis]

Beaucoup plus compréhensible et simple !

[francois-ferrandis]

Ah, on crée des services en cascade et donc on doit les supprimer ensuite, c'est ça ?

Je te propose cette implem d'un trait :no_service dans la factory :

    # [...]
    invitation_accepted_at { Time.zone.parse("2020-07-30 10:30").in_time_zone }

    transient do

      service { build(:service) }
      no_service { false }

      trait :no_service do
        no_service { true }
      end
    end
    after(:build) do |agent, evaluator|
      next if evaluator.no_service
      next if agent.agent_services.any?
      next if agent.services.any?

      agent.services = if evaluator.service
                         [evaluator.service]
                       else
                         [build(:service)]
                       end
    end

    transient do
      basic_role_in_organisations { [] }
    end

    # [...]

[francois-ferrandis]

Et si dans app/controllers/admin/agents_controller.rb:24 on utilise Agent.new(create_agent_params.merge(...)), ça nous permet d'ajouter des conditions sur les services dans la policy. Je ne sais pas si on veut aller jusque là, c'est juste pour évoquer le sujet.

Disons que là je vois qu'on utilise des service_ids qui ne sont jamais observés dans la policy, et donc ça fait sonner l'alerte, mais bon, c'est des service_ids, pas de user_ids. Mais quand même, ça peut être une faille d'escalade de droits dans le futur.

[victormours]

Mises à jour suite aux suggestions de Matis :