Fix/allowedtypes picker enforcement

[wpelczar]

Fixes #58.

Makes [AllowedTypes] / RestrictedTypes actually take effect in the category picker. The 2.1.0 change for #56 point 7 (PR #57) did not work in practice — #58 has the full diagnosis; the short version is two independent defects.

What was wrong

1. The attribute never reached the editor on the [Categories] path. CategoryEditorMetadata read it from the propertyAttributes handed to CategoriesAttribute.CreateDisplayMetadata, i.e. context.Attributes. CMS builds that context in ExtensibleMetadataProvider.ApplyMetadataAwareAttributes as:

var attributesForType = ModelAttributes.GetAttributesForType(metadata.GetType());
var ctx = new DisplayMetadataProviderContext(key, attributesForType);

— the attributes of the ExtendedMetadata class, not of the property. So AllowedTypesAttribute was never present, ResolveAllowedTypes silently returned its typeof(CategoryData) fallback, and the picker offered every category type. RestrictedTypes was lost the same way.

This was path-specific: CategoriesEditorDescriptor (the [UIHint] path) is an IMetadataExtender, invoked with propertyMetadata.Attributes, so it did receive the real set. The broken path is the one the 2.0.0 README and CHANGELOG recommend.

2. Delegating the allow-filter to the shell store cannot work for a nested tree. typeIdentifiers on contentstructure filters rather than marks: GetChildrenQuery restricts children to the requested type, so intermediate "container" categories are removed and every allowed category nested beneath them becomes unreachable. On a tree shaped root -> grouping category -> allowed category, the picker renders completely empty.

There is no value that satisfies both goals. Including an ancestor type so the container survives re-admits every sibling type, because the store matches via the item's whole descriptor ancestor chain (DefaultContentQueryHelper.FilterTypeIdentifier → UIDescriptorRegistry.HasMatchedTypeIdentifier). Restricting the leaves and exposing the containers are mutually exclusive through that parameter.

So fixing 1 alone turns a permissive picker into an empty one. Both had to move together.

What this changes

• Attribute resolution. New CategoryEditorMetadata.ResolvePropertyAttributes falls back to ExtendedMetadata.Attributes when the supplied set carries no AllowedTypesAttribute. That is the property's own attribute list on both wiring paths, and the same source CMS's own AllowedTypesMetadataExtender uses.
• Enforcement moves from filtering to disabling. getChildren always requests the base category type, so the tree stays complete and navigable. Allowed/restricted types are evaluated per node by the existing Selectable endpoint, and disallowed nodes are disabled but still shown and expandable — the same "grey, don't hide" approach as the native picker (ContentTree + disableRestrictedTypes). A disallowed container is therefore still a path to the allowed categories under it.
• Type matching stays server-side, via UIDescriptorRegistry.HasMatchedTypeIdentifier — the same call CMS makes itself. A base type matches all its subtypes, which lines up with AllowedTypesAttribute's publish-time validation, and the package does not have to model the type hierarchy in JavaScript. (Doing it in the client would need the polymorphic match too: for a typeof(...)-declared type, AllowedTypesMetadataExtender emits only the lowercased FullName, so string equality would wrongly reject subtypes.)
• Search is now type-gated as well. It never was: SearchResultStore binds no typeIdentifiers parameter, so the values the client sent were silently discarded. Search hits now go through the same Selectable pass as tree nodes, so the request no longer sends type identifiers that cannot be honoured.

Behaviour changes worth a reviewer's opinion

• Restricted types are now disabled rather than removed from the tree and search. This is deliberate — hiding them breaks navigation exactly the way narrowing typeIdentifiers does — but it is a visible change from 2.1.0, so flagging it explicitly.
• Disallowed categories are visible in the picker instead of absent. That is the native picker's behaviour, and it is what keeps nested hierarchies reachable, but it is a UX decision you may want to weigh.
• EditorConfiguration["AllowedTypes"] / ["AllowedDndTypes"] now hold type identifier strings instead of System.Type instances, matching the CMS convention for those keys. For properties that declare [AllowedTypes], CMS's own extender overwrote these anyway; for a property relying on the package default, they were previously serialised System.Type objects.

API surface

• CategoryEditorController constructor gains a UIDescriptorRegistry parameter — binary-breaking for anything constructing it directly, though as an MVC controller it is resolved by DI.
• Selectable(string ids) → Selectable(string ids, string allowedTypes = null, string restrictedTypes = null). Source-compatible for existing callers, binary-breaking.
• CategorySelectableResponse gains Reason (notSelectable / typeNotAllowed, exposed as CategoryEditorController.NotSelectableReason / TypeNotAllowedReason) so the picker can explain why a row is disabled. Additive.

The CHANGELOG entry is under ## [Unreleased] — move it under whichever version you plan to ship.

Tests

27 pass (17 before, 10 new):

• ResolvePropertyAttributes — the regression guard for defect 1, covering the fallback, precedence when both sets carry the attribute, the empty case, and RestrictedTypes surviving the fallback.
• Selectable — the type gate: allowed vs. disallowed, restricted taking precedence over allowed, IsSelectable taking precedence over the type check, no registry call when no allow-list is supplied, and unresolvable ids staying selectable.

The registry is stubbed rather than built from real UIDescriptor instances, because UIDescriptor's public constructor resolves ViewConfiguration / IContentTypeRepository through ServiceLocator. The polymorphic matching itself is CMS's contract, so the tests cover the controller's own logic: which gate wins, and which reason is reported.

Note I could not run the full-solution build locally — the sub/geta-foundation-core submodule is not part of my checkout — so the sandbox is unverified on my side. CI checks out submodules recursively, and this change touches neither the sandbox nor the submodule.

Verification

Manually verified against a large production solution currently being migrated to CMS 13 / .NET 10 under Optimizely Identity (management UI at /ui), on a category tree of ~25 category types nested behind non-selectable container categories, with 56 [Categories] properties of which 20 declare [AllowedTypes]. Tested via a locally packed build of this branch, so the module zip and buildTransitive delivery path were exercised too, not just the assembly.

Confirmed:

• The tree shows the full hierarchy; the non-selectable container is visible and expandable, greyed with "This category is not selectable".
• Allowed categories nested under it are selectable; categories of other types are greyed with "This category type cannot be selected for this property".
• Searching for a disallowed category by name returns it, disabled.
• A plain [Categories] property with no [AllowedTypes] still offers every category type, selectable.
• [Categories] and [UIHint(CategoryUIHint.Categories)] behave identically — the point of the fix.
• Publish-time validation still behaves as before.

Attribution

The investigation and the code were done with Claude Code. The root cause was found by decompiling the CMS 13.1.0 assemblies to trace how typeIdentifiers and the metadata pipeline actually behave, then confirmed empirically rather than inferred — the widgetSettings capture in #58 is the direct evidence. Every claim about CMS internals in #58 and in the code comments is checkable against the shipped assemblies.

Happy to reshape any of this — particularly the disable-vs-hide decision — if you would rather solve it a different way.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud