تزامن SSO API الخاص بـ Discourse مع custom_fields يؤدي إلى ظهور "custom.custom.<field>" في الحمولة

ساهم خلل
1

يتوقع DiscourseApi::SingleSignOn أن تُخصص السمات المخصصة على النحو التالي:

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

# ما ينتج عنه مفتاح `custom.field_1` في الحمولة

يتوقع DiscourseApi::API::SSO.sync_sso() أن تحتوي المعاملات على:

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

لكنها تمرر بادئة custom. إلى sso.custom_fields
وهذا يؤدي إلى أن تحتوي الحمولة على:

custom.custom.field_1

تم أيضًا إضافة بعض الاختبارات المفرطة لـ sync_sso

إعجاب واحد (1)
2

كان من الممكن أن يكون هذا أسهل بكثير في رأيي، لكنني لا أريد كسر التطبيقات الحالية :grimacing:. دعنا نترك توليد مثيل SSO للمستخدم.

# 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

ربما غداً سأفعل شيئاً مشابهاً (لكن أنظف)

# 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)
          .... نفس الوضع الحالي
        end
      end
    end
  end
end

ما رأيكم؟ ستمتلك طلبي مثالياً دالة واحدة تولد DiscourseApi::SingleSignOn، وحينها سأتمكن من تمريرها إلى sso_login أو sync_sso

أو يمكن تعريف المعاملات كالتالي

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

وهو ما سيكسر أيضاً التطبيقات الحالية.

إعجابَين (2)
3

تم إصلاح هذه المشكلة الشهر الماضي:

إعجابَين (2)