U4-158 - Allow root doctypes

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

Comments

Sebastiaan Janssen 18 Jan 2013, 12:50:32

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.


Jan Skovgaard 31 Jan 2013, 20:03:08

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.


Sarah Green 13 Mar 2013, 17:25:29

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


Sebastiaan Janssen 14 Mar 2013, 07:32:53

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.


Sarah Green 14 Mar 2013, 08:13:19

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?


Sebastiaan Janssen 14 Mar 2013, 08:16:12

@Sarah They're in the dashboards.config, but they still work when you don't have access to the Content root node though.


Sarah Green 14 Mar 2013, 08:20:40

That was my point!


Sebastiaan Janssen 14 Mar 2013, 08:59:19

@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


Sarah Green 14 Mar 2013, 09:51:31

@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.


Sebastiaan Janssen 14 Mar 2013, 10:33:33

@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.


Sarah Green 14 Mar 2013, 11:07:05

@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.


Simon Dingley 14 Mar 2013, 11:16:26

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?


Sarah Green 14 Mar 2013, 11:22:11

I think its a matter of usability but agree we've reached the end of the road here.


Funka! 19 Mar 2013, 17:56:57

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?


Sebastiaan Janssen 19 Mar 2013, 18:55:23

@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: