How best to handle custom fields defaults and category setting logs

Development

AI-generated summary

A discussion on handling custom fields defaults and category setting logs is ongoing. angus explains that when editing a category, unnecessary log entries are created due to the activitypub plugin setting default values for custom fields. This is because core logs all category custom field changes, including when a field is set to its default value.

angus questions whether logging these changes makes sense, as it does not necessarily indicate a change in the category’s settings configuration. david agrees that this is a tricky issue, but suggests a possible core API change to improve the situation. He proposes using a raw HTML input field to gain control over how values are read and written to the model instance, allowing for the removal of default value configurations and unnecessary log entries.

david provides example code for this approach, using an input field with a conditional statement to set the value to null when the default value is selected. This would prevent unnecessary log entries from being created.

1

Some context

The reason this occurs is because

  1. The activity pub plugin sets some defaults for those fields on the client (here).

  2. All category custom field changes are logged as category setting changes in core (here).

“1” (setting category custom field defaults on the client) seems to be the best way to work with the category custom field pipeline at the moment as the update category action will automatically save them, and you want to ensure the defaults are being set if the custom fields are interdependent (as they are in the AP plugin).

Note that it’s not currently possible for a plugin to selectively serialize custom fields to the server (without monkey patching).

Given the above, I’m wondering whether “2” makes sense? As David points out, given the current configuration of the pipeline, a change in a custom field doesn’t necessarily indicate a change in the settings configuration of the category (i.e. going from nil to the default).

Curious to hear others’ takes on this. Perhaps I’m missing a better way of handling category custom field defaults.

2

@david Just bumping this up your list again. Where is your gut on this? If you think a change to how category custom field saving might be needed in core I can give that shot. Or perhaps I’ll see if I can find a new way of setting defaults for custom fields. Or perhaps we leave it for now?

3

Yeah this is tricky. I suppose most plugins don’t run into this because their ‘default’ for the category setting is a null value.

Did you have an idea for a core API change which could help improve the situation?

Totally untested, but I think we might be able to swing something right now by using a raw HTML input field (note lowercase input instead of Ember’s two-way-bound <Input component).

<input
  value={{or category.custom_fields.my_field "default value"}}
  {{on "change" this.updateMyFieldValue}}
/>

With that strategy, we have control over how values are read/written to the model instance. So, if a value is set to the default in the UI, we can write that as ‘null’ in the custom fields:

@action
updateMyFieldValue(event){
  let newValue = event.target.value;
  if(newValue === "default value"){
    newValue = null;
  }

  this.category.set("custom_fields.my_field", newValue);
}

(and then you would remove the default value configuration you described in (1) of the OP)