[sneridagh]

Step 3 of #2061. Stacked on #2070.

What a behaviors UI needs: the order of a type's behaviors, what each behavior adds, and a preview of the edit form with other behaviors.

@content-types: ordered behaviors

• A behaviors fieldset for Dexterity types, with one field, behaviors: the complete, ordered list of the type's behaviors. Their order sets where their fields appear in the edit form.
• PATCH replaces the list: a behavior left out is disabled. It's a List of Choices from the registered behaviors, so unknown or repeated behaviors return 400 with the field's error.
• Behaviors are listed by their name (plone.dublincore), also when the FTI stores the interface identifier or a former dotted name.
• Behaviors stored on the type that aren't registered (an uninstalled add-on) aren't listed, and a PATCH keeps them, so they come back with their add-on.
• The fieldset's order is 45, before versioning. The service writes fieldsets in order, so in a PATCH that changes both, the versioning setting decides about the versioning behavior, as it does when it changes alone.

GET /@behaviors

• Every registered behavior once (they're registered under their name and their interface identifier), sorted by name, with name, title, description and fieldsets: the fields it adds to the edit form, by fieldset. The fields are computed with the same autoform processing as the edit form, so fieldset directives apply. The list is empty for behaviors that add no fields.
• Same permission as @content-types.

GET /@types/{type}?behaviors=a,b,…

• A dry run: the schema the type would have with these behaviors, in this order. The type doesn't change.
• get_jsonschema_for_fti, get_jsonschema_for_portal_type and get_info_for_type take an optional behaviors list. A new behavior_form_schemata builds the form schemata from it, like getAdditionalSchemata does from the FTI.
• An empty value previews the schema without behaviors. Unknown behaviors return 400, and non-Dexterity types return 404.

Docs

• content-types.md: the behaviors setting, with an example
• a new behaviors.md
• types.md: "Preview the schema with other behaviors"
• New http examples: content_types_patch_behaviors, behaviors_get (request only, the list is long) and types_get_with_behaviors (request only). content_types_get_item.resp and content_types_post.resp gain the fieldset.

Tests

• test_services_contenttypes.py, 7 new tests:
  • the ordered list and its JSON schema
  • PATCH replacing it in order, with the type schema following
  • legacy names listed by name
  • unregistered behaviors kept
  • unknown and repeated behaviors refused without changes
  • versioning deciding about its behavior
  • no fieldset for non-Dexterity types
• test_services_behaviors.py: listing, fields by fieldset, behaviors without fields, and permissions
• test_services_types.py: the preview, an empty preview, and an unknown behavior

Full suite: 1508 tests. 7 fail, and the same 7 fail on #2070's branch: date-dependent tests in test_workflow, test_search and test_statictime.

The Aurora UI that uses this is plone/aurora#335. Its driver switches to these endpoints in a follow-up.

[read-the-docs-community]

Documentation build overview

📚 plone.restapi | 🛠️ Build #35564840 | 📁 Comparing 522773a against latest (1cca588)

  🔍 Preview build  

9 files changed · + 1 added · ± 8 modified

+ Added

• endpoints/behaviors.html

± Modified

• endpoints/aliases.html
• endpoints/breadcrumbs.html
• endpoints/comments.html
• endpoints/content-rules.html
• endpoints/content-types.html
• endpoints/types.html
• endpoints/users.html
• usage/content.html

[sneridagh]

LGTM

[sneridagh]

@jenkins-plone-org please run jobs

[davisagli]

I reviewed the docs, but not the implementation yet.

[davisagli]

I think we should use plone.app.controlpanel.Types

[davisagli]

Why are you including these choices inline instead of using the existing Behaviors vocabulary? It's a bit redundant to include a copy of the choices in each type's settings schema when it's already available as a vocabulary.