We have moved to GitHub Issues
You are viewing the read-only archive of Umbraco's issue tracker. To create new issues, please head over to GitHub Issues.
Make sure to read the blog posts announcing the move for more information.
Created by Sebastiaan Janssen 07 Aug 2012, 10:00:55 Updated by Sebastiaan Janssen 16 Aug 2017, 05:12:19
Is duplicated by: U4-3
Is duplicated by: U4-303
Is duplicated by: U4-10297
Relates to: U4-1500
Relates to: U4-1563
Relates to: U4-1914
Subtask of: U4-112
Change the behaviour of doctypes to never allow them to be created in under the root content node. Only allow that when a checkbox on the doctype is set to true.
1 Attachments
One deviation: if no document types are set to allowed at root level, all of them will be allowed. That way we have full backwards compatibility.
Maybe it would be nice if that information is also added in the help text? I was almost filing a bug report because I was allowed to create all of my document types under the root node without having decided which ones should be allowed.
Would it not have been better to have made the property "Disallow at root" from the outset? This would then have been fully backwardly compatible but would have enabled the needed functionality of preventing users from creating duplicate root nodes when it is not appropriate
If you have 83 doctypes, you don't want to go and disallow them one by one. Generally what we've seen is that people want to allow one or two doctypes at root. And as always, if you only have one root node then give the editors only access to that, that way they'll never even have to run into this at all.
I guess it depends whether backwards compatibility is more or less important than new features ... if disabling access is considered to be best practice then is there a way to move the change password and last edits tabs somewhere else so that these are not also disabled?
@Sarah They're in the dashboards.config, but they still work when you don't have access to the Content root node though.
That was my point!
@Sarah.. so you don't want them? Just remove them from dashboards.config or change the access permissions: http://our.umbraco.org/wiki/reference/files-and-folders/dashboardconfig
@Sebastiaan ... we seem to be at cross purposes here ... maybe my misunderstanding but if I prevent users from being able to access the "Content" node (as suggested by you above) then they also lose the ability to change their passwords and see "Last Edits" ... What I'm after is a way to prevent users from adding duplicate "home nodes" whilst RETAINING the ability to change password and see last edits.
@Sarah As said: If you limit the editor's view to just one root node, they will still see the change pw/last edits dashboard just by going to /umbraco/#content (I've attached a screenshot). Now, of course they don't have the "Content" top node to click on. But by logging in, going "/umbraco/#content" in the browser or just refreshing their browser window they will still see the dashboards.
@Sebastiaan - I am aware of the workaround but as you quite rightly point out users have no obvious way of navigating to these tabs since there is no Content node .. in my experience this really confuses users. Telling them to type in an obscure url or to refresh their browser to get something to appear is not something that is intuitive or user-friendly. However, I realise we digress from the main topic and I guess I'll just put the whole thing down as another one of Umbraco's little idiosyncrasies.
As Sebastiann says, you don't need the content tree to be able to see those controls. I think it might be worth posting your issue on the forum as it sounds to me like there is some misunderstanding or over-complication of the matter?
I think its a matter of usability but agree we've reached the end of the road here.
Sooo, this feature was added and is now available in 6.0.0, right? The history on this item is a little confusing to me; it shows this was resolved five months ago in 4.10, but then a few days later removed from 4.10. And then a couple of months later re-targeted for 6.0.0, but no other build or changeset notices since then. My secondary motive is to inquire if any plans to back-port to the 4.11.x+ family?
@Funka No it's not going to be in 4.11.x due to a required database change for this (which is why it moved from 4.10 to 6.0.0).
Priority: Normal
Type: Task
State: Fixed
Assignee: Niels Hartvig
Difficulty: Normal
Category:
Backwards Compatible: True
Fix Submitted:
Affected versions:
Due in version: 6.0.0
Sprint:
Story Points:
Cycle: