# How best to handle custom fields defaults and category setting logs
**URL:** https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063
**Category:** Development
**Created:** [October 23, 2023, 5:50am UTC](https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063 "2023-10-23T05:50:57Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [October 23, 2023, 5:50am UTC](https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063/1 "2023-10-23T05:50:57Z")
Some context
> [@ActivityPub Plugin](https://meta.discourse.org/t/activitypub-plugin/266794/101):
>
> I just went to edit a category here on Meta (to change some group access permissions). I didn’t change any activitypub-related settings, but we ended up with these three entries in the staff log:
>
> 
> I guess they technically went from `nil` to their default value, so there is no actual change in behaviour? Still, it would be good to avoid this remove logging to avoid confusion.
The reason this occurs is because
1. The activity pub plugin sets some defaults for those fields on the client ([here](https://github.com/discourse/discourse-activity-pub/blob/main/assets/javascripts/discourse/connectors/category-custom-settings/activity-pub-category-settings.js)).
2. All category custom field changes are logged as category setting changes in core ([here](https://github.com/discourse/discourse/blob/main/app/services/staff_action_logger.rb#L562)).
“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.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [November 10, 2023, 11:50am UTC](https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063/2 "2023-11-10T11:50:25Z")
@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?
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [November 10, 2023, 12:27pm UTC](https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063/3 "2023-11-10T12:27:41Z")
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 `
```
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:
```js
@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)