Fügen Sie eine benutzerdefinierte Einstellung pro Benutzer in einem Plugin hinzu

Community-Wiki Entwickler
,
1

Ich habe diesen Prozess gerade durchlaufen und dabei einige Versuche und Irrtümer erlebt, daher habe ich meine Erkenntnisse dokumentiert, um dem nächsten Entwickler zu helfen, der dies nachvollziehen muss.

Die Dinge, die ich benötigte:

  • Registrieren Sie Ihren benutzerdefinierten Feldtyp (meiner war boolean, Standard ist string)

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

  • Registrieren Sie, dass das benutzerdefinierte Feld von Benutzern bearbeitet werden kann. Die Syntax entspricht der von params.permit(...)

    # plugin.rb
register_editable_user_custom_field :my_preference # Skalartyp (string, integer, etc.)
register_editable_user_custom_field [:my_preference , my_preference : []] # Für Array-Typ
register_editable_user_custom_field [:my_preference,  my_preference : {}] # Für JSON-Typ

  • Fügen Sie sie den Feldern hinzu, die mit dem CurrentUserSerializer serialisiert werden

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

  • Erstellen Sie eine Komponente, um Ihre Benutzerpräferenz anzuzeigen

    // assets/javascripts/discourse/templates/components/my-preference.hbs
<label class="control-label">Meine benutzerdefinierten Präferenzen!</label>
{{preference-checkbox labelKey="my_plugin.preferences.key" checked=user.custom_fields.my_preference}}

  • Verbinden Sie diese Komponente mit einem der Präferenz-Plugin-Ausgänge (meiner befand sich unter ‘interface’ in den Benutzerpräferenzen)

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

  • Stellen Sie sicher, dass ‘benutzerdefinierte Felder’ auf diesem Präferenz-Tab gespeichert werden

    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()
           }
         }
       })

     })
  }
}

Dieses Dokument wird versioniert – schlagen Sie Änderungen auf GitHub vor.

33 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
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 „Gefällt mir“
10

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

3 „Gefällt mir“
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 „Gefällt mir“
12

Dies ist ein sehr hilfreicher Beitrag, der ein direktes Beispiel für die Einrichtung eines benutzerdefinierten Felds für Benutzer zeigt. Gibt es etwas Ähnliches, das bei der Einrichtung eines einfachen benutzerdefinierten Felds für Themen hilft? Ich versuche gerade, dies hier zu lösen:

Aber es funktioniert noch nicht ganz. Ich würde mich sehr über jede Hilfe dazu freuen.

1 „Gefällt mir“
14

David,

Das scheint nicht mehr zu funktionieren?

Wir haben verwendet:

  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

um das Speichern eines JSON-Objekts in einem benutzerdefinierten Feld zu ermöglichen, aber dies verhindert jetzt, dass Websites neu erstellt werden!

Wir verwenden dies seit einiger Zeit.

Der Fehler, den wir während des Builds erhalten, ist:

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!'

Zu der Verwirrung trägt bei, dass dies in der Entwicklung zu funktionieren scheint, aber nur bei einem Produktions-Build fehlschlägt.

Wenn es entfernt wird, wird die Website erstellt, aber das benutzerdefinierte Feld des Benutzers wird nicht gespeichert und schlägt lautlos fehl.

Ich sehe nicht, dass sich dies seit Jahren geändert hat?:

Blockiert eine neue Version von Rails dies jetzt?

2 „Gefällt mir“
15

@Falco könnte dies mit Ruby 3.x zusammenhängen?

2 „Gefällt mir“
16

Zu Ihrer Information, ich habe lokal 2.7.1 für die Entwicklung installiert (ups) … ich behebe das gerade.

3 „Gefällt mir“
17

Ja, das hängt definitiv mit Ruby 3.1.x zusammen. Es funktioniert gut mit 2.7.x.

2 „Gefällt mir“
18

Ich habe das Plugin mit Standardeinstellungen in meiner lokalen Umgebung mit dem aktuellen Ruby installiert und aktiviert. Wie kann ich den Fehler auslösen?

1 „Gefällt mir“
19

Nun, das ist das Problem. rbenv erlaubt mir nicht, Ruby über 3.0.2 zu installieren, und in der Entwicklung (? was fehlt mir?) kann ich den Fehler in der Entwicklung nicht auslösen. Aber sobald Sie versuchen, eine aktuelle tests-passed-Instanz mit dem Locations-Plugin auf dem production_fixes-Branch zu erstellen (ignorieren Sie den Namen, er ist kaputt).

1 „Gefällt mir“
20

Es ist übrigens 3.1.3. Wenn Sie Vorschläge offen sind, funktioniert asdf für mich hervorragend.

Cool, ich werde es versuchen.

2 „Gefällt mir“
21

Entschuldigung, ich glaube, ich habe den Build-Fehler in diesem Branch tatsächlich behoben. Ich dachte nicht, dass es funktionieren würde, aber das scheint zumindest zu kompilieren. Ich teste gerade die Funktionalität:

Es scheint, wenn man diesen Trick verwendet:

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

wie von David oben vorgeschlagen, funktioniert es?

1 „Gefällt mir“