Add setting unwantedControlPanelsFields and use it in the function filterControlPanelsSchema #4819
Conversation
✅ Deploy Preview for volto ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
wesleybl
force-pushed
the
controlpanel_filter
branch
from
95b1589 to
81a6aaa
Compare
Passing run #5325 ↗︎
Details:
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
|||||||||||||||
news/4819.feature
Outdated
| @@ -0,0 +1 @@ | |||
| Replaces ``filterControlPanelsSchema`` setting by ``unwantedControlPanelsFields`. @wesleybl | |||
There was a problem hiding this comment.
| Replaces ``filterControlPanelsSchema`` setting by ``unwantedControlPanelsFields`. @wesleybl | |
| Renames `filterControlPanelsSchema` setting to `unwantedControlPanelsFields`. @wesleybl |
There was a problem hiding this comment.
Removing support for a custom filterControlPanelsSchema function is a breaking change that could only happen in a new major version of volto. I'd suggest keeping it, but change the default implementation to use the new unwantedControlPanelFields setting. Then it can be backported for volto 16.
@davisagli but isn't the master branch for Volto 17, which is a breaking release? Can't we keep |
|
@wesleybl Yeah, we can make this change for 17. In general my bias is to keep backwards compatibility if it's easy. But that does inflate the number of options over time, and in this particular case I doubt the filterControlPanelsSchema setting is being used much. Any preference, @sneridagh? |
|
@wesleybl I'm with @davisagli in this one... agreed that it cleans up the implementation, but that is hardly a reason for introducing a breaking if there is not delivering a clear direct advantage over the previous one. |
wesleybl
force-pushed
the
controlpanel_filter
branch
from
81a6aaa to
26c4c02
Compare
✅ Deploy Preview for plone-components canceled.
|
|
@davisagli @sneridagh @stevepiercy I kept the Can you take a look please? |
wesleybl
force-pushed
the
controlpanel_filter
branch
from
04f2756 to
a3d42a0
Compare
wesleybl
changed the title
There was a problem hiding this comment.
One minor grammar correction to the narrative docs made me notice that there might be a grammatical mistake in the naming of the schema factory. Why do use filterControlPanelsSchema and unwantedControlPanelsFields instead of filterControlPanelSchema and unwantedControlPanelFields? Obviously it is not worth refactoring the deprecated filterControlPanelsSchema, but it might be worth refactoring the new factory to unwantedControlPanelFields. I understand that the endpoint is @controlpanels. Thoughts?
|
|
@wesleybl let's leave it as is without a refactor. Plural makes sense. I made a minor change to my suggestion, and if you accept, then I can approve and move this forward. Thank you! |
unwantedControlPanelsFields filterControlPanelsSchema has been migrated to Controlpanel.jsx and uses the unwantedControlPanelsFields setting. So, if any portal wants to add fields in the Control Panel, it will be necessary to customize only the unwantedControlPanelsFields configuration, instead of customizing the entire filterControlPanelsSchema function.
Co-authored-by: Steve Piercy <[email protected]>
wesleybl
force-pushed
the
controlpanel_filter
branch
from
a49236f to
35894b9
Compare
|
@davisagli @ichim-david I updated the code and resolved the conflicts. Can we merge it? |
filterControlPanelsSchemahas been migrated toControlpanel.jsxand uses theunwantedControlPanelsFieldssetting. So, if any portal wants to add fields in the Control Panel, it will be necessary to customize only theunwantedControlPanelsFieldsconfiguration, instead of customizing the entirefilterControlPanelsSchemafunction.This is an improvement for #3904