Skip to content
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

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from
1 change: 1 addition & 0 deletions plone-6.0.x.cfg
Original file line number Diff line number Diff line change
Expand Up @@ -20,3 +20,4 @@ robotframework-assertion-engine = 2.0.0
robotframework-debuglibrary = 2.3.0
robotframework-pythonlibcore = 4.2.0
grpcio-tools = 1.59.0
readme_renderer = 43.0
mamico marked this conversation as resolved.
Show resolved Hide resolved
5 changes: 4 additions & 1 deletion src/plone/restapi/types/utils.py
Original file line number Diff line number Diff line change
Expand Up @@ -229,7 +229,10 @@ def get_jsonschema_for_fti(fti, context, request, excluded_fields=None):
fieldsets = ()
additional_schemata = ()
else:
additional_schemata = tuple(getAdditionalSchemata(portal_type=fti.id))
if fti.id == context.portal_type:
additional_schemata = tuple(getAdditionalSchemata(context=context))
else:
additional_schemata = tuple(getAdditionalSchemata(portal_type=fti.id))
Copy link
Member

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?

Copy link
Member Author

@mamico mamico Oct 17, 2024

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?

Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davisagli Your position is clear, and I absolutely agree with you. Do you have any suggestions for the parameter name to use? Something like .../@types/Document?contextual=1 ?

fieldsets = get_fieldsets(context, request, schema, additional_schemata)

# Build JSON schema properties
Expand Down
Loading