Element picker: Add allowed element types configuration

[NguyenThuyLan]

Prerequisites

• I have added steps to test this contribution in the description below
  (Element Picker: Add setting "Allow items of type" #22851)

Description

Adds an "Allow items of type" configuration option to the Element Picker property editor, allowing editors to restrict which element types can be selected.

How to test

1. Create a new Data Type using the Element Picker editor.
2. In the "Allow items of type" config field, select one or more element types (e.g. only "Promo Block").
3. Save the Data Type and assign it to a Document Type property.
4. Open a content node, open the Element Picker — verify only elements of the allowed type(s) are selectable in the tree.
5. Leave "Allow items of type" empty — verify all element types remain selectable (no restriction).
6. Configure multiple allowed types — verify all of them are selectable and others are not.

[claude]

Claude finished @NguyenThuyLan's task in 6m 43s —— View job

---

PR Review

Target: origin/main · Based on commit: acbd2ae8
· Skipped: 0 noise files out of 9 total

Adds an "Allow items of type" configuration option to the Element Picker property editor, restricting which element types can be selected. Touches the C# value editor (new AllowedTypeValidator), the configuration model, four frontend TypeScript components, and a new unit test class.

• Modified public API: ElementPickerConfiguration (new AllowedContentTypeIds property); stored value format changed from ["guid"] to [{"type":"element","unique":"guid"}]
• Affected implementations (outside this PR): ElementPickerValueConverter reads the old format and was not updated
• Other changes: New allowedContentTypes data-type config field visible in the backoffice; umb-input-element selection property type changed from Array<string> to Array<UmbReferenceByUniqueAndType>

---

Critical

• src/Umbraco.Core/PropertyEditors/ValueConverters/ElementPickerValueConverter.cs:70 (not changed in this PR): GetElements still does _jsonSerializer.Deserialize<Guid[]>(value). This PR changes the stored format to [{"type":"element","unique":"..."}], so Deserialize<Guid[]> will return null for every new value → all element picker properties render empty in templates and the Delivery API. ElementPickerValueConverter must be updated to extract GUIDs from the new object format before this PR can merge. Fix this →

Important

• src/Umbraco.Core/PropertyEditors/ElementPickerPropertyEditor.cs:70: The stored value format change (from GUID array to object array) is not accompanied by a content migration or a dual-format reader. The codebase is at v18.1.0-rc, meaning existing installations may already have element picker values saved in the old ["guid"] format. After this PR, GetReferences silently yields nothing for those values, losing all entity-tracking references. Add a fallback in GetReferences that tries the old Guid[] format when the new format deserialization returns null.

• src/Umbraco.Core/PropertyEditors/ElementPickerPropertyEditor.cs:119: AllowedTypeValidator calls GetByIds and only validates elements that were found. If a submitted element key doesn't exist (deleted element, or crafted request), it is silently treated as valid. A malicious editor could bypass the type restriction by submitting a key for a non-existent element alongside forbidden-type elements. Consider returning a validation failure when elements.Length differs from the number of distinct keys, or document this as accepted behavior.

Suggestions

• tests/Umbraco.Tests.UnitTests/Umbraco.Core/PropertyEditors/ElementPickerPropertyEditorValidationTests.cs:3: using System.Data is imported but never used — remove to keep the file clean.

• tests/Umbraco.Tests.UnitTests/Umbraco.Core/PropertyEditors/ElementPickerPropertyEditorValidationTests.cs: Test method names (Allowed_Type_Passes_..., Allowed_Type_Fails_...) deviate from the project's Can_/Cannot_ convention. Consider renaming to e.g. Can_Validate_With_No_Filter_Configured, Cannot_Validate_When_Element_Type_Is_Disallowed.

---

Request Changes

The Critical issue (value converter not updated) must be addressed — it causes a complete regression for anyone using the Element Picker in templates or the Delivery API after this PR ships. The data migration concern is also worth resolving before merging since this is a release candidate.

The feature itself is well-structured: the backend validator, configuration model, and frontend components are cleanly implemented, and the unit tests cover the key scenarios.

[claude]

Claude finished @NguyenThuyLan's task in 5m 17s —— View job

---

Claude finished @NguyenThuyLan's task in 6m 43s —— View job

---

PR Review

Target: origin/main · Based on commit: 88f2e6fc · Skipped: 0 noise files out of 9 total

Adds "Allow items of type" configuration to the Element Picker property editor: a backend AllowedTypeValidator that queries element content types at save time, a new ElementPickerConfiguration.AllowedContentTypeIds property, and a frontend config UI that filters the picker tree at selection time.

• Modified public API: ElementPickerConfiguration — new AllowedContentTypeIds property; ElementPickerPropertyValueEditor constructor — 3 new parameters (ILocalizedTextService, IElementService, ICoreScopeProvider)
• Other changes: New allowedContentTypes data-type config field visible in the backoffice; umb-input-element gains a new allowedContentTypeIds property; UmbElementTreePickerDataSource.treePickableFilter now conditionally filters by content type

---

Important

• src/Umbraco.Core/PropertyEditors/ElementPickerPropertyEditor.cs:85: jsonSerializer is accepted in the ElementPickerValidatorRunner constructor but never stored or used — dead parameter. Remove it from the constructor signature and the corresponding call site at line 55–57.

• src/Umbraco.Core/PropertyEditors/ElementPickerPropertyEditor.cs:143: When a submitted element key doesn't exist in the database, GetByIds silently omits it — its type is never checked. An editor could include a non-existent or crafted key alongside valid ones to bypass the allowed-type restriction. Consider failing validation when elements.Length != value.Length, or document this as accepted behaviour.

Suggestions

• src/Umbraco.Web.UI.Client/src/packages/elements/global-components/input-element.element.ts:2: Two commented-out imports remain in the file (lines 2 and 8). Remove them before merging.

---

Approved with Suggestions for improvement

The previous Critical issue (value converter regression) has been resolved, and the overall structure is clean. Please address the dead parameter and review the silent-bypass behaviour before merging.

[AndyButland]

I had a quick look over @NguyenThuyLan. I haven't tested as I wanted to give you some feedback that you'd have in the morning. Looks great so far, but I found a few things to suggest inline.

Don't forget also that we discussed on the Azure board story that we wanted to align the document picker with this and the media picker for validation. It's also missing the ability to select allowed types, so we should introduce that. And I think it makes sense to do so in this PR, so we can see it's all aligned and guarantee that it's released together (in C# the document picker is called ``ContentPickerPropertyEditor(with nestedContentPickerPropertyValueEditor`).

In the end we'd like to get the document, media and element picker all as aligned as we can in terms of features, validation and how they are handled client and server-side.

[AndyButland]

I don't know if we need this check do we? The media picker equivalent doesn't do it. I would say a missing element would simply contribute no type alias to the check. Also the invalidObjectType response isn't really reflecting what's failed in the check.

[NguyenThuyLan]

This is to solve a problem found by Claude: the key doesn't exist in the database; GetByIds silently omits it from the result array — its type is never checked.
I have changed invalidObjectType to missingContent.

[AndyButland]

OK, I guess that's reasonable. If we don't know what the ID is, we don't know what type it is, and therefore we can't validate that it's of that type. But in that case we should look to add it to the media and document (content) picker too, so they are aligned.

[AndyButland]

The media picker equivalent also has MinMaxValidator and StartNodeValidator. If the element picker supports those configurations, then we should also server-side validate them.

[NguyenThuyLan]

Currently, Element Picker doesn't have min/max configurations. Is it possible to add this option to Element Picker?

[AndyButland]

Yes, I think they are worth adding. In general we should look to align the document (content), media and element pickers.