Discourse_api sync_sso custom_fields resulta en "custom.custom.<field>" en el payload

DiscourseApi::SingleSignOn espera que los atributos personalizados se asignen así:

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

# lo que resulta en la clave `custom.field_1` en el payload

DiscourseApi::API::SSO.sync_sso() espera que los parámetros tengan:

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

Pero pasa el prefijo custom. a sso.custom_fields
Esto hace que el payload tenga:

custom.custom.field_1

También se agregaron algunas pruebas excesivas para sync_sso

1 me gusta

Esto habría sido mucho más sencillo, en mi opinión, pero no quiero romper las aplicaciones existentes :grimacing:. Deja que el usuario se encargue de la generación de instancias 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

Quizás mañana haga algo así (pero más limpio)

# 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)
          .... igual que actualmente
        end
      end
    end
  end
end

¿Qué opinas? Idealmente, mi aplicación tendrá una única función que genere DiscourseApi::SingleSignOn, y luego podré pasarla a sso_login o sync_sso.

O los parámetros se podrían definir así:

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

Lo cual también rompería las aplicaciones existentes.

2 Me gusta

Se realizó una corrección para esto el mes pasado:

2 Me gusta