-
-
Notifications
You must be signed in to change notification settings - Fork 610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editable layout does not work well when portal_type has a Schema #6170
Comments
@mauritsvanrees As discussed this afternoon, this issue looks similar to a previous one that was reported and fixed on plone.restapi as that's where the behaviors are implemented: plone/plone.restapi#1476. There the inheritance was fixed so that IEditableBlocks inherits from IBlocks if I understand it correctoy, but as you write the decorators are not inherited. |
I am beginning to fear that what we want is not possible. The problem is:
This is done by Volto in So when editable blocks are enabled, the two fields are taken from the schema. This explains why it is fine that the And they must be defined in the That explains why the current way is fine for the standard Document type, which does not have a schema class. In our use case, with a portal_type that has a filesystem schema class (like the empty But the Note that an FTI has a In other words: when an FTI defines a schema class, the In fact, you get the same problem when you try to add a simple field, not blocks related, even just in Classic UI:
So: this is not going to work. :-( |
I've scanned your analysis, but am not grasping it yet fully. The stranges part: If it is not possible, why has apparently worked for 3-4 years since this feature has been implemented? Or is the implementation used in customer projects different from the core implementation? Also: this is Plone backend, assuming this did work @avoinea @ichim-david @tiberiuichim Would you be so kind to check or ask around with colleagues how you have been using this feature in past projects? I assume it was developed as a functional requirement at the time. @mauritsvanrees theory/workaround if we would add the FTI model as an xml model that gets loaded on startup instead of Python schema class, then that is loaded in the model_source. Is that the way this could still work in current implementations? |
Yes, switching to an XML model instead of a Python schema would work. Or start with standard blocks behavior, hack Volto the way I do above (forcing
|
Just to be clear on this point still. It has probably always only worked for portal_types that have their schema defined in XML. Or that do not have a schema at all yet, and only have behaviors. Or types that have a model_file on file system, because the model_file is the one that is checked last. Corrolary is also: if the type has a model_file with some fields in it, and you enable the editable layout, then the fields in the model_file will be ignored, at least after restart. (I did not try this, but this is what I expect based on my current knowledge.)
|
I would say that enabling the the Editable Layouts has been this flaky from the beginning. I mean: it has worked when the relevant conditions were met, but when you have the conditions as explained by Maurits it was working as explained. We have faced several issues when enabling the Volto blocks TTW, and we have always seen this kind of behavior. We ended going to the ZMI, and removing/adding the relevant properties in the model_source. I would say that we would need to identify when is supossed to work OK, and allow only setting the behavior on that cases. |
@mauritsvanrees Indeed, this is exactly how it works 🙈 We also use this as a behavior in one of our projects https://github.com/eea/eea.dexterity.indicators/blob/master/eea/dexterity/indicators/interfaces.py#L179-L662 The |
Describe the bug
Editable blocks layout works fine on the standard Document type, but it has problems on types that have a Schema:
The first problem led me to believe that I should enable both the
volto.blocks
andvolto.blocks.editable.layout
behaviors. But that is not what the "Enable editable blocks" button in the Layout control panel does: it switches off the standardvolto.blocks
(if this is enabled) and enablesvolto.blocks.editable.layout
. And that works fine for Documents.Let me first say how to solve this, and then explain how to reproduce this.
plone.restapi.behaviors
theIBlocksEditableLayout
class needs an extra line@provider(IFormFieldProvider)
, just likeIBlocks
already has. This provider does not get inherited. Without this provider, the editable layout behavior seems to have no fields becauseplone.dexterity.utils.getAdditionalSchemata
finds no form schema for it. (I don't know why this part does work for the standard Document type.)This change leads to two differences:
blocks
(andblocks_layout
) field got reported as belonging to a behavior with a name likeplone.dexterity.schema.generated.Plone_5_1721241704_2_695599_0_Document
(an on the fly Schema for Documents) or whatever "real" Schema you have in the Schema portal type. But now it belongs to the behavior that you would expect:volto.blocks.editable.layout
readOnlyBehavior
inContentTypeLayout.jsx
needs to be updated. It should continue to check forgenerated
as it does now (so it keeps working for Documents when someone uses a currentplone.restapi
release). But it should also check forvolto.blocks.editable.layout
so it works when theplone.restapi
fix has landed. So something like:I can make PRs later.
Wait, now it seems I can go to the layout page, I can add blocks and save the layout, but when I reload the page, I have a blank layout again ?? I need to check what is going on there... :-/
To Reproduce
Steps to reproduce the behavior:
plone.supermodel.model.Schema
.Software (please complete the following information):
The text was updated successfully, but these errors were encountered: