-
-
Notifications
You must be signed in to change notification settings - Fork 76
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
fix: get schemata defined in the context #1796
base: main
Are you sure you want to change the base?
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
✅ Deploy Preview for plone-restapi canceled.
|
Co-authored-by: Steve Piercy <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fingers crossed!
@jenkins-plone-org please run jobs |
@jenkins-plone-org please run jobs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixes for news items only. This PR needs a review from a maintainer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but this still needs a review from a maintainer. Thank you!
if fti.id == context.portal_type: | ||
additional_schemata = tuple(getAdditionalSchemata(context=context)) | ||
else: | ||
additional_schemata = tuple(getAdditionalSchemata(portal_type=fti.id)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mamico Can you help me understand the logic here? What is the scenario where we can't or shouldn't pass the context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davisagli thanks for asking for clarification and putting me doubts...
The api is called to know the schema at the creation of a new CT or to know the schema at the modification of a content. In the first case I expected it to always be called from the root of the portal (but I'm wrong), in the second case it is called from the context of the object, and it would be useful to request the schema by passing the context.
So currently it is called (ie by Volto) as:
/++api++/@types/Document
creation in the root
/++api++/folder/@types/Document
creation in a folder
/++api++/folder/doc1/@types/Document
modification of /folder/doc1
... but also ...
/++api++/folder/doc1/@types/Document
to the creation of a new document inside doc1
... here the modification I proposed behaves incorrectly (doc1.portal_type
is equal to Document
but the correct schema is the generic schema, not the contextual).
I am putting the PR back in draft because it needs to be rethought in some way.
Suggestions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mamico It's important to get the schema for new content items in the context of its container, because some vocabularies might be context-dependent. (i.e. a list of keywords that depends on what section you are in)
So maybe we need a parameter so that the schema can be requested with or without context-dependent behaviors. Then they could be included by default, but the add form could request it without this.
get schemata for behaviors defined in the context. ie using a
plone.dexterity.behavior.DexterityBehaviorAssignable
adaptersee https://github.com/collective/collective.instancebehavior/