# Como lidar melhor com padrões de campos personalizados e logs de configuração de categoria

**URL:** <https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063>\
**Category:** Development\
**Created:** [Outubro 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:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\
**Post date:** [Outubro 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")

</div>

Algum contexto

> [@david](#):
>
> Acabei de editar uma categoria aqui no Meta (para alterar algumas permissões de acesso de grupo). Não alterei nenhuma configuração relacionada ao activitypub, mas acabamos com estas três entradas no log de staff:
> 
> ![image](https://global.discourse-cdn.com/meta/original/4X/c/6/2/c6230bd860269b531139a99b77078b2cba9acee9.png)  
> Suponho que tecnicamente eles foram de `nil` para seu valor padrão, então não há nenhuma alteração real no comportamento? Ainda assim, seria bom evitar esse registro de remoção para evitar confusão.

O motivo pelo qual isso ocorre é porque

1. O plugin activity pub define alguns padrões para esses campos no cliente ([aqui](https://github.com/discourse/discourse-activity-pub/blob/main/assets/javascripts/discourse/connectors/category-custom-settings/activity-pub-category-settings.js)).

2. Todas as alterações de campo personalizado de categoria são registradas como alterações de configuração de categoria no core ([aqui](https://github.com/discourse/discourse/blob/main/app/services/staff_action_logger.rb#L562)).

“1” (definir padrões de campo personalizado de categoria no cliente) parece ser a melhor maneira de trabalhar com o pipeline de campo personalizado de categoria no momento, pois a ação de categoria `update` os salvará automaticamente, e você deseja garantir que os padrões sejam definidos se os campos personalizados forem interdependentes (como são no plugin AP).

> <https://github.com/discourse/discourse/blob/main/app/controllers/categories_controller.rb#L185>

Observe que atualmente não é possível para um plugin serializar seletivamente campos personalizados para o servidor (sem monkey patching).

Dado o exposto, estou me perguntando se “2” faz sentido? Como David aponta, dada a configuração atual do pipeline, uma alteração em um campo personalizado não indica necessariamente uma alteração na configuração de configurações da categoria (ou seja, ir de nil para o padrão).

Estou curioso para ouvir as opiniões de outros sobre isso. Talvez eu esteja perdendo uma maneira melhor de lidar com os padrões de campo personalizado de categoria.

---

_[View the full topic](https://meta.discourse.org/t/how-best-to-handle-custom-fields-defaults-and-category-setting-logs/283063)._