Add demo content type for facet conditions testing without polluting package consumers

[reekitconcept]

Background

Facet conditions are a feature of the current version. This is best demonstrated with a customized Person content type, for example:

• person.building: which building the person is in
• person.room: room number of the person

Then in the People search, we can show facet conditions for building and room.

Why we need this

• Demo site: Users can easily understand and test out the feature
• Cypress tests: Tests can exercise the UX with this setup

The problem

We don't want to add a customized Person type to the main package. Consumers of this package might not want to use Person at all, or use a differently customized Person. (In contrast: kitconcept.intranet does contain a Person type, but it's a different package which some users of kitconcept.solr will not want to use.)

Proposed solution

Add a DemoPerson content type that is only configured in:

• The Cypress test setup
• The demo site

This content type should NOT be registered when someone just uses the package as a dependency.

Monorepo consideration

This pattern should be supported from the monorepo format, as adding a demo site and running a specific setup for Cypress can be a common requirement for other packages as well.

Implementation Plan

• Create a DemoPerson content type with building and room fields
• Add Solr schema configuration for building and room indexes
• Create a separate ZCML profile (e.g., demo or testing) that registers DemoPerson
• Configure the demo site to load the demo profile
• Configure Cypress test setup to load the demo profile
• Ensure the main package profile does NOT include DemoPerson
• Add facet conditions configuration for building and room in the demo/testing context
• Create sample DemoPerson content in demo site fixtures
• Write Cypress tests exercising facet conditions with the demo content
• Document the pattern for other packages needing similar demo/testing-only content types

[reekitconcept]

cc @davisagli — I'd value your perspective on the best approach for including and configuring the DemoPerson content type so it's available for demos/tests but not for regular package consumers.

cc @ericof — I'd value your perspective on how this pattern could fit into the distribution effort, particularly regarding extending the monorepo template to support demo/testing-only content types.

[davisagli]

@reekitconcept I agree with the approach of creating a "demo" profile that adds this content type, and then make sure it is installed for Cypress and for the demo site in this repository.

We already do something like that for kitconcept.voltolighttheme:

• There is a demo profile https://github.com/kitconcept/volto-light-theme/tree/main/backend/src/kitconcept/voltolighttheme/profiles/demo
• It's installed when the demo site is created https://github.com/kitconcept/volto-light-theme/blob/main/backend/scripts/create_site.py#L122
• There is also an acceptance profile which is installed in the Dockerfile used for acceptance tests: https://github.com/kitconcept/volto-light-theme/blob/fb760b505867619bed3fdd419a5c28c093a39cb3/backend/Dockerfile.acceptance#L33 (There's no important reason it's a separate profile, only that the demo profile includes example content that we didn't need for the acceptance tests.)