-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Added option for filtering the content types allowed as children based on the parent node #18380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added option for filtering the content types allowed as children based on the parent node #18380
Conversation
…d on the parent node.
…nt-item-when-filtering-allowed-children
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments about obsoletion messages.
Its best to put the version at the end of the message and used the wording Scheduled for removal
or Scheduled to be removed
as we have had complaints about things that were obsoleted with stricter removal indications not actually being removed.
I will test the implementation soon™
src/Umbraco.Cms.Api.Management/Controllers/MediaType/AllowedChildrenMediaTypeController.cs
Outdated
Show resolved
Hide resolved
...Umbraco.Cms.Api.Management/Controllers/DocumentType/AllowedChildrenDocumentTypeController.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Sven Geusens <[email protected]>
@@ -56,20 +56,20 @@ export class UmbCreateDocumentCollectionActionElement extends UmbLitElement { | |||
|
|||
override async firstUpdated() { | |||
if (this._documentTypeUnique) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @AndyButland
I think this needs to check for this._documentUnique !== undefined
@@ -56,20 +56,20 @@ export class UmbCreateDocumentCollectionActionElement extends UmbLitElement { | |||
|
|||
override async firstUpdated() { | |||
if (this._documentTypeUnique) { | |||
this.#retrieveAllowedDocumentTypesOf(this._documentTypeUnique); | |||
this.#retrieveAllowedDocumentTypesOf(this._documentTypeUnique, this._documentUnique || null); | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And here, I would suggest firing a proper Error, describing why it did not work.
like: "Could not retrieve Document Type Unique or Parent Document Unique"
@@ -56,20 +56,20 @@ export class UmbCreateDocumentCollectionActionElement extends UmbLitElement { | |||
|
|||
override async firstUpdated() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally this is not handled on firstUpdated, instead I would suggest observing both workspaceContext.unique
and workspaceContext.contentTypeUnique
in one Observe..
this style: this.observe(observeMultiple([workspaceContext.unique, workspaceContext.contentTypeUnique]), ...
And then once both have a value call the this.#retrieveAllowedDocumentTypesOf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These points make sense @nielslyngsoe - but you are commenting on lines and patterns that weren't part of this PR. I'm probably not the person best placed to refactor so if it's OK with you, can I leave to you to amend if you see fit to do so please?
Prerequisites
Resolves issue raised in discussion: #16329 (reply in thread)
Description
We discussed and introduced a server-side replacement for "sending allowed children notification" in 15.2, via this PR, but it had a bit of a design flaw for use for a typical use case where you want to allow only a certain number of items of content of a given type to be created.
We made available the parent document type to the filter, but not the parent content item. So when filtering allowed types under a given item, you didn't have the details of that item available.
I've resolved with this PR but it needed a bit more update than the previous, as we need to pass the detail of which item we are creating under up to the method that retrieves the allowed children, and where the filtering occurs.
To Test:
I've used and registered the following example to verify and test this, that can be adapted for other use cases: