Elements: Split content type validation for create and update#21906
Merged
lauraneto merged 10 commits intoMar 6, 2026
Merged
Conversation
…lements no longer permitted in library
…t-type-validation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts ElementEditingService content-type validation so element creation still enforces IsElement + AllowedInLibrary, while element updates only require that the content type exists—allowing existing elements to remain editable even if their type is later disallowed from the library.
Changes:
- Split content type validation into
ValidateContentTypeForCreate(strict) andValidateContentTypeForUpdate(existence-only). - Apply the create/update-specific validation in
ValidateCreateAsync/ValidateUpdateAsyncand in theCreateAsync/UpdateAsyncflows. - Remove reliance on the previous
TryGetAndValidateContentTypeoverride approach for these checks.
Verify that ElementEditingService.UpdateAsync succeeds when the content type's AllowedInLibrary flag is set to false after the element was created, covering the split validation introduced for create vs update.
Eliminate redundant content type lookups in CreateAsync and UpdateAsync by moving the IsElement/AllowedInLibrary check into the TryGetAndValidateContentType override, which distinguishes create from update by checking if the model is a ContentCreationModelBase.
…t-type-validation
…t-type-validation
Migaroez
approved these changes
Mar 5, 2026
Migaroez
left a comment
Contributor
There was a problem hiding this comment.
Looks good to me, left some suggestions but nothing that feels blocking to me. Feel free to merge as is or implement the suggestions.
…t-type-validation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
ElementEditingServicepreviously enforced bothIsElementandAllowedInLibrarychecks on every content type validation, regardless of whether the operation was a create or an update. This meant that if an element type was later disallowed from the library, existing elements of that type could no longer be saved/updated.This PR updates the
TryGetAndValidateContentTypeoverride to distinguish between create and update operations by checking if the model is aContentCreationModelBase:Additionally, the
ValidateCreateAsyncmethod now performs its own content type lookup andIsElement/AllowedInLibraryvalidation before delegating toValidateCulturesAndPropertiesAsync, ensuring the validation endpoint also rejects disallowed types on create.An integration test was added to verify that updating an element succeeds after its content type has been disallowed from the library.
Testing
Create an element type that is allowed in the library and create an element of that type. Then update the element type to no longer be allowed in the library. Verify that the existing element can still be saved/updated, but new elements of that type cannot be created.