Is there anyway to restrict the creation of multiple content items of a particular content type in a folder? Ie. Can I restrict navon / navTree items so that there would only be one per folder?
For what we want, validating a sys_title and forcing uniqueness in the folder will work, but I just was wondering if there were a more elegant solution.
For Navons and NavTree, the NavFolderEffect should limit you to one item (of these types) per folder. Are you able to create more than one?
Yup, I can create multiple navons in the same folder.
How do i trigger this “navFolderEffect”. Note that we copied over the rffNavon and renamed them (also changed navigation.properties appropriately).
Also can i use this (from the above answer) to apply to other content types?
The NavFolderEffect is attached to the Folder Relationship. Whenever you create a folder (or add a folder to a folder) it checks for Navons / NavTree and adjusts the relationships. It also prevents you from having more than one Navon / NavTree per folder.
The effect gets the names of the content types from Navigation.properties. If you changed the names (and navigation.properties) double check to make sure that they match.
As with all relationship configuration, any changes here take effect at the next server restart
On the same kind of thought process, is there a way to restrict certain content item creation to a certain folder, e.g. if we had a news folder, could we restrict it so that only the news content type could be used in that folder?
Yes, that would be a nice feature to have as well…Folder specific content types. Although, for all of what RX cares about, a folder is a content item itself and just holds a symbolic link to the content items “within” it. It would be nice if this were possible though…
For dbenua: Yes i have verified that the names on the content types in navigation.properties are the same (as the ones we’re using for navigation)
What we have done on our side to manage only certain content types in a specific folder is by creating communities. We have a community name “Headline” that have permission to create only “HEadlines” conten item and that have write access only in this specific folder.
Hope it will help you,
Yes we looked into this option, but it wouold put an unreasonable amount of effort onto our users to keep changing between communities when it would be great if we could just have more flexibility in the way the “create item” menu is handled.
We would also like it to show different options in the “create item” menu when people have different roles, just like all the other menu options.
I believe it can be done, but it requires using undocumented XML formats. It will survive an upgrade if coded properly. This is not trivial, but should be doable by a competent Rx/Java developer.
(I haven’t tested this, so there may be gotchas lurking.)
If you just want to limit the list of content types in a menu based on some data such hiding ctypes for items already in the folder, or hiding all ctypes except those types allowed in a folder, here’s what you would do.
First, modify the Create_New_Item action. Add a new parameter sys_folderid = $sys_contentid and repoint the URL to a new servlet that will perform the filtering.
Create the servlet - it should perform the query originally done by the action, then process the returned document to filter out the types that should be hidden.
If you want to limit a folder to a certain content type, one way of doing this would be to add a custom property to the folder that contained the list of allowed types. The servlet would look up the folder, find this list (if present) and filter accordingly. If no property was present, the list wouldn’t be filtered. Another way would be to create a properties file that matched folder ids to a list of content type ids (or names.)
If you want to allow only 1 instance of a type in the folder, then the servlet would get all the children of the folder and filter based on their types.
Both of these techniques are good for the user, but don’t enforce the policy. A clever user could still subvert the policy and add undesirable children. To enforce the policy, you would need to add an effect to the Folder relationship similar to the NavFolderEffect (which cannot be used for other content types.) This effect would do work similiar to what the servlet would do to determine if the creation of the folder relationship was allowed. In fact, if you wanted enforcement and a proper list of types in the UI, you would want to factor your code such that it could be shared by the effect and the servlet.
Forgot to update, but for dbeuna, our problem with navons (ability to add multiple ones) is caused by the solution to prevent automatic navon creation
So i guess that begs the question…is there a way to restrict automatic navon creation without disabling the navfolderEffect?