Discourse_api sync_sso custom_fields führt im Payload zu "custom.custom.<field>"

Beitragen Fehler
1

DiscourseApi::SingleSignOn erwartet, dass benutzerdefinierte Attribute wie folgt zugewiesen werden:

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

# was zu einem `custom.field_1`-Schlüssel im Payload führt

DiscourseApi::API::SSO.sync_sso() erwartet, dass die Parameter wie folgt aufgebaut sind:

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

Es wird jedoch das custom.-Präfix an sso.custom_fields übergeben.
Dies führt dazu, dass der Payload folgendes enthält:

custom.custom.field_1

Außerdem wurden einige überflüssige Tests für sync_sso hinzugefügt.

1 „Gefällt mir“
2

Das wäre meiner Meinung nach viel einfacher gewesen, aber ich möchte keine bestehenden Apps brechen :grimacing:. Überlassen Sie die Generierung der SSO-Instanz dem Benutzer.

# 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

Vielleicht mache ich morgen etwas Ähnliches (aber etwas sauberer):

# 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)
          .... identisch mit der aktuellen Version
        end
      end
    end
  end
end

Was haltet ihr davon? Mein App soll idealerweise eine einzige Funktion haben, die DiscourseApi::SingleSignOn generiert, und ich könnte sie dann an sso_login oder sync_sso übergeben.

Oder die Parameter könnten so definiert werden:

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

Was ebenfalls bestehende Apps brechen würde.

2 „Gefällt mir“
3

Dies wurde letzten Monat behoben:

2 „Gefällt mir“