Discourse_api sync_sso custom_fields résulte en "custom.custom.<field>" dans le payload

Contribuer Bug
1

DiscourseApi::SingleSignOn s’attend à ce que les attributs personnalisés soient assignés comme suit :

sso.custom_fields['field_1'] = 'value'

# ce qui se traduit par la clé `custom.field_1` dans le payload

DiscourseApi::API::SSO.sync_sso() s’attend à ce que les paramètres contiennent :

{ 'custom.field_1' => 'value' }

Mais il transmet le préfixe custom. à sso.custom_fields
Cela entraîne que le payload contient :

custom.custom.field_1

J’ai également ajouté quelques tests excessifs pour sync_sso

1 « J'aime »
2

Cela aurait été beaucoup plus simple à mon avis, mais je ne veux pas casser les applications existantes :grimacing:. Laissez la génération de l’instance SSO à l’utilisateur.

# frozen_string_literal: true
module DiscourseApi
  module API
    module SSO
      def sync_sso(sso)
        post("/admin/users/sync_sso", sso.payload)
      end
    end
  end
end

Peut-être que demain je ferai quelque chose comme ça (mais plus propre)

# frozen_string_literal: true
module DiscourseApi
  module API
    module SSO
      def sync_sso(params)
        if params.instance_of?(DiscourseApi::SingleSignOn)
          post("/admin/users/sync_sso", sso.payload) 
        elsif params.instance_of?(Hash)
          .... identique à l'actuel
        end
      end
    end
  end
end

Qu’en pensez-vous ? Mon application aura idéalement une fonction unique qui génère DiscourseApi::SingleSignOn, et je pourrai alors la passer à sso_login ou sync_sso

Ou les paramètres peuvent être définis comme suit

{
  sso_secret: ...
  name: ...
  custom_fields: {
    field_1: ...
  }
}

Ce qui casserait également les applications existantes.

2 « J'aime »
3

Une correction a été apportée à ce sujet le mois dernier :

2 « J'aime »