Adicione uma configuração personalizada por usuário em um plugin

Wiki da comunidade Desenvolvedores
,
1

Acabei de passar por esse processo e enfrentei bastante tentativa e erro, então decidi documentar minhas descobertas para ajudar o próximo desenvolvedor que passar por aqui.

O que eu precisava:

  • Registrar seu tipo de campo personalizado (o meu era booleano, o padrão é string)

    # plugin.rb
User.register_custom_field_type 'my_preference', :boolean

  • Registrar que o campo personalizado deve ser editável pelos usuários. A sintaxe corresponde à de params.permit(...)

    # plugin.rb
register_editable_user_custom_field :my_preference # Tipo escalar (string, integer, etc.)
register_editable_user_custom_field [:my_preference , my_preference : []] # Para tipo array
register_editable_user_custom_field [:my_preference,  my_preference : {}] # para tipo json

  • Adicioná-los aos campos serializados com o CurrentUserSerializer

    # plugin.rb
DiscoursePluginRegistry.serialized_current_user_fields << 'my_preference'

  • Criar um componente para exibir sua preferência de usuário

    // assets/javascripts/discourse/templates/components/my-preference.hbs
<label class="control-label">Minhas preferências personalizadas!</label>
{{preference-checkbox labelKey="my_plugin.preferences.key" checked=user.custom_fields.my_preference}}

  • Conectar esse componente a um dos outlets de plugin de preferências (o meu estava em ‘interface’ nas preferências do usuário)

    # assets/javascripts/discourse/connectors/user-preferences-interface/my-preference.hbs
{{my-preference user=model}}

  • Garantir que os ‘campos personalizados’ sejam salvos na aba de preferências

    import { withPluginApi } from 'discourse/lib/plugin-api'

export default {
  name: 'post-read-email',
  initialize () {
     withPluginApi('0.8.22', api => {

       api.modifyClass('controller:preferences/emails', {
         actions: {
           save () {
             this.get('saveAttrNames').push('custom_fields')
             this._super()
           }
         }
       })

     })
  }
}

Este documento está sob controle de versão - sugira alterações no github.

33 curtidas
Add a plugin based custom user field to the create account form?
Problem updating user custom_fields created by a plugin
"wrong number of arguments" on Upgrade to new version
Extend Existing Controller?
Developer Index
Could a List of Recommended Topics Be Added to the Top Menu?
2

Nice! I attempted the same in GitHub - mozilla/discourse-post-read-email: INACTIVE - http://mzl.la/ghe-archive - A discourse plugin to give users the option of marking posts as read when emailed and arrived at almost the same result.

My only differences were I didn’t hunt down User.register_custom_field_type and so used my own ugly workaround. (I’ll switch to register_custom_field_type when I get the chance.)

And I think I came up with a slightly neater solution for saving the field, I patch the preferences controller to save custom fields alongside everything else, so the field is saved when the “Save” button is clicked, rather than when it’s toggled:

import { withPluginApi } from 'discourse/lib/plugin-api'

export default {
  name: 'post-read-email',
  initialize () {
     withPluginApi('0.8.22', api => {

       api.modifyClass('controller:preferences/emails', {
         actions: {
           save () {
             this.saveAttrNames.push('custom_fields')
             this._super()
           }
         }
       })

     })
  }
}

This should work for all preferences controllers, as they all seem to use saveAttrNames.

10 curtidas
3

As a follow-up here, it turns out that inline-edit-checkbox is available only in the adminjs package, meaning this is currently Bad Advice™. I’ve resorted to using the method suggested above alongside the preference-checkbox component

{{preference-checkbox labelKey="my_plugin.preferences.key" checked=model.custom_fields.my_field}}

which works for all users.

Also, @LeoMcA, I had to modify your preferences hack slightly to work with the interface page since saveAttrNames was a computed property there.

this.get('saveAttrNames').push('custom_fields')
5 curtidas
4

Per DEV: Allow plugins to whitelist specific user custom_fields for editi… · discourse/discourse@4382fb5 · GitHub, custom fields must now be added to a whitelist to allow editing by users. All that is needed is a single line in plugin.rb:

register_editable_user_custom_field :my_field

@gdpelican @LeoMcA I have updated the OP with this extra step, and also pulled in the comments from your second and third posts. Please feel free to update anything else you feel is necessary.

8 curtidas
5

Perfect, thanks for this - I had fixing discourse-post-read-email on my todolist after last week’s security commit, and this makes it a whole lot easier!

Question (which may belong in a seperate post):

Will this serialize the custom field as an array, even if it only has a single element in it? I’ve been having to use the following pattern in a seperate plugin, so that:

user.custom_fields["field1"] = [ :item ]
user.save_custom_fields

becomes:

Array(user.custom_fields["field1"])
> [ :item ]

rather than:

user.custom_fields["field1"]
> :item
2 curtidas
6

This change only deals with saving custom fields, so I don’t think it will affect how they are serialized.

That said, I do know that there are a lot of weird edge cases relating to custom fields which we are hoping to address in a few weeks time (after 2.1 is released). What you describe above looks like one of those weird cases that we need to improve.

6 curtidas
7

Note that if the user custom field is a JSON string, you need to include the keys, or an empty hash (if the keys are dynamic), for it to be permitted, e.g.

register_editable_user_custom_field geo_location: {}
3 curtidas
8

hm, in a slight pickle actually. If the custom field is JSON, in order to save it, you need to pass a hash, i.e.

register_editable_user_custom_field geo_location: {}

will permit

{"custom_fields"=>{"geo_location"=>{"lat"=>"-37.7989239", "lon"=>"144.8929753", "address"=>"Barkly Street, Footscray, City of Maribyrnong, Greater Melbourne, Victoria, 3011, Australia", "countrycode"=>"au", "city"=>"", "state"=>"Victoria", "country"=>"Australia", "postalcode"=>"3011", "boundingbox"=>["-37.7989854", "-37.7988961", "144.8928258", "144.8931743"], "type"=>"tertiary"}}>

However, if the param is empty (e.g. the user clears the field), the custom_field is interpreted as a string

{"custom_fields"=>{"geo_location"=>"{}"}}

and is not permitted.

There isn’t an easy way around this in the current structure, i.e. the way user_params are added to in the users_controller

permitted << { custom_fields: User.editable_user_custom_fields }

Unless I’m missing something, perhaps some additional provision needs to be made for user_custom_fields that are typecast as JSON?

1 curtida
9

I had a similar problem with arrays, not sure if the same will work for JSON. To allow an empty array, you have to permit ‘scalar’ values as well as an array:

register_editable_user_custom_field :geo_location
register_editable_user_custom_field geo_location: []

Or if you’re feeling fancy it can be combined into one line:

register_editable_user_custom_field [ :geo_location, geo_location: [] ]

This is the same behaviour as params.permit(...), so I hesitate to call it a bug. Maybe we can call it a ‘quirk’ :wink:

Let me know if that approach works for JSON - if not we can work out another solution

6 curtidas
10

:facepalm: of course. Just add another. It’s been a long day. Thanks!

3 curtidas
11

Visiting this again, it feels like there are too many steps here for something that the core plugin system has a command for. On the backend, I have to write the following to make this go:

# plugin.rb
register_editable_user_custom_field :my_setting
User.register_custom_field_type 'my_setting', :boolean
DiscoursePluginRegistry.serialized_current_user_fields << 'my_setting'

but I feel like I should be able to do this:

# plugin.rb
register_editable_user_custom_field :my_setting, :boolean

You could even avoid people running into that nasty array snag by making the plugin system support the following cases:

register_editable_user_custom_field :my_setting, :array
register_editable_user_custom_field :my_setting, :object

@david

10 curtidas
12

Este é um post muito útil que apresenta um exemplo direto de como configurar um campo personalizado de usuário. Existe algo semelhante para ajudar a orientar a criação de um campo personalizado simples para tópicos? Estou tentando resolver isso aqui:

Mas ainda não consegui fazê-lo funcionar. Agradeceria muito qualquer ajuda sobre isso.

1 curtida
14

David,

Isso não parece mais funcionar?

Temos usado:

  register_editable_user_custom_field [:geo_location,  geo_location: {}] if defined? register_editable_user_custom_field
  register_editable_user_custom_field geo_location: {} if defined? register_editable_user_custom_field

para permitir o salvamento de um objeto JSON em um campo personalizado do usuário, mas isso agora está impedindo a reconstrução dos sites!

Temos usado isso há algum tempo.

O erro que estamos recebendo durante a compilação é:

ArgumentError: wrong number of arguments (given 0, expected 1)
/var/www/discourse/lib/plugin/instance.rb:170:in `register_editable_user_custom_field'
/var/www/discourse/plugins/discourse-locations/plugin.rb:95:in `block in activate!'

Para aumentar a confusão, isso parece funcionar em desenvolvimento, mas falha apenas durante uma compilação de Produção.

Se removido, o site será compilado, mas o campo personalizado do usuário não será salvo e falhará silenciosamente.

Não vejo que isso tenha mudado em anos?:

Uma nova versão do Rails está bloqueando isso agora?

2 curtidas
15

@Falco isso pode estar relacionado ao Ruby 3.x?

2 curtidas
16

FYI, tenho a versão 2.7.1 instalada localmente para desenvolvimento (ops)… estou corrigindo isso agora.

3 curtidas
17

Sim, está definitivamente relacionado ao Ruby 3.1.x. Funciona bem no 2.7.x.

2 curtidas
18

Tenho o plugin instalado e habilitado com as configurações padrão no meu ambiente local com o Ruby atual, como posso acionar o erro?

1 curtida
19

Bem, esse é o problema. O rbenv não me permite instalar o Ruby além do 3.0.2 e em desenvolvimento (? o que estou perdendo?) não consigo acionar o erro em desenvolvimento. Mas assim que você tenta compilar uma instância atual de tests-passed com o Plugin de Localizações no branch production_fixes (ignore o nome, está quebrado).

1 curtida
20

É 3.1.3 a propósito. Se você estiver aberto a sugestões, asdf funciona muito bem para mim.

Legal, vou tentar.

2 curtidas
21

Desculpe, acho que na verdade corrigi o erro de build naquele branch. Não achei que funcionaria, mas isso, aparentemente, pelo menos compila, estou apenas testando a funcionalidade agora:

Parece que se você usar este truque:

 register_editable_user_custom_field [:geo_location,  geo_location: {}] if defined? register_editable_user_custom_field

sugerido por David acima, funciona?

1 curtida