As I understand it, the only way to control which documents an editor can create/edit/delete/publish is by choosing their start node?
In the case, say, of an intranet, there might be users who can edit 'news' documents but nothing else.
Would I then create a news 'root' node, with news items being allowable child documents.
But if I then give those users the news 'root' node as their starting point, yes, they can create news documents as planned, but surely they can also edit, unpublish (!) or even delete (!!!!!!!!!!!!!) the 'root' node which destroys everything.
No doubt that user management unfortunately has some limitations currently - It's something that has been discussed at several occasions and I think the big issue is that rewriting that logic will require a big amount of code refactoring unfortunately - It might not be as easy to fix in the core as it seems.
So HQ are aware of it but I don't think that a decision has been made in regards to how and when a potential refactor is to be made. I'm afraid that there is no silver bullet and if work is started on fixing this then it's something that will probably take a long time to finish since there are many scenarios that will need to be taken into account. But hopefully some day it will happen...But I think it's safe to say that it will not be happening in the near future.
However I'm wondering how your intranet is going to work? Are people going to be using it from the Umbraco backoffice? Or are you making use of the "Frontend editing" package (Can't quite remember the correct name of the package at this time of writing).
I'm thinking that perhaps your intranet could make use of "Members" instead of "Users" since in my perception of an intranet it's something that needs to be handled this way rather than having Umbraco users.
You can define member groups and by assigning groups to the members you can control their access levels - Then in your content tree you can setup "public" access on a node-tree and select, which groups are allowed to visit these nodes/pages from your website.
In your views you will then of course also need to make a check to see whether the visitor is a member who has been logged into the intranet and whether the member type has access to certain areas of the page. There are some methods/helpers for this available - You can see them on the Razor cheat sheet here https://our.umbraco.org/projects/developer-tools/umbraco-v6-mvc-razor-cheatsheets/ (it's probably also documented elsewhere but this is just from the top of my mind).
In terms of editing nodes from the intranet you will then of course need to build your own editing functions using the ContentService and perhaps the Member API instead. You can learn more about the API's here https://our.umbraco.org/documentation/Reference/Management/Services/
That's probably how I would approach building an intranet - But of course I don't know your specifications and requirements etc. and this is of course also something that requires time to build, which means you will have to perhaps dicuss the economy with the client etc. - So I'm aware that changing the approach to what I describe above might not be as straight forward as it may sound - But perhaps it can be worth the effort in the long wrong instead of having to struggle with the potential limitations that can be encountered basing this on users instead of members.
I hope this can be used to perhaps approach building the intranet in another fashion perhaps.
User access on documents
As I understand it, the only way to control which documents an editor can create/edit/delete/publish is by choosing their start node?
In the case, say, of an intranet, there might be users who can edit 'news' documents but nothing else.
Would I then create a news 'root' node, with news items being allowable child documents.
But if I then give those users the news 'root' node as their starting point, yes, they can create news documents as planned, but surely they can also edit, unpublish (!) or even delete (!!!!!!!!!!!!!) the 'root' node which destroys everything.
My testing seems to support this.
Is there another way?
there was a handy disucssion about this on twitter very recently
https://twitter.com/greystate/status/732868606493655040
the most useful part was @Umbraco shared a video showing I think what maybe you'd need here:
https://t.co/FIstsGyRaq
interesting, I'll watch the video.
I do think user access is possibly the weakest part of Umbraco.
(and in the tweets = 'multiple logins' for multiple nodes. Hmm, I can imagine how popular that would be with users!)
Hi Tim
No doubt that user management unfortunately has some limitations currently - It's something that has been discussed at several occasions and I think the big issue is that rewriting that logic will require a big amount of code refactoring unfortunately - It might not be as easy to fix in the core as it seems.
So HQ are aware of it but I don't think that a decision has been made in regards to how and when a potential refactor is to be made. I'm afraid that there is no silver bullet and if work is started on fixing this then it's something that will probably take a long time to finish since there are many scenarios that will need to be taken into account. But hopefully some day it will happen...But I think it's safe to say that it will not be happening in the near future.
However I'm wondering how your intranet is going to work? Are people going to be using it from the Umbraco backoffice? Or are you making use of the "Frontend editing" package (Can't quite remember the correct name of the package at this time of writing).
I'm thinking that perhaps your intranet could make use of "Members" instead of "Users" since in my perception of an intranet it's something that needs to be handled this way rather than having Umbraco users.
You can define member groups and by assigning groups to the members you can control their access levels - Then in your content tree you can setup "public" access on a node-tree and select, which groups are allowed to visit these nodes/pages from your website.
In your views you will then of course also need to make a check to see whether the visitor is a member who has been logged into the intranet and whether the member type has access to certain areas of the page. There are some methods/helpers for this available - You can see them on the Razor cheat sheet here https://our.umbraco.org/projects/developer-tools/umbraco-v6-mvc-razor-cheatsheets/ (it's probably also documented elsewhere but this is just from the top of my mind).
In terms of editing nodes from the intranet you will then of course need to build your own editing functions using the ContentService and perhaps the Member API instead. You can learn more about the API's here https://our.umbraco.org/documentation/Reference/Management/Services/
That's probably how I would approach building an intranet - But of course I don't know your specifications and requirements etc. and this is of course also something that requires time to build, which means you will have to perhaps dicuss the economy with the client etc. - So I'm aware that changing the approach to what I describe above might not be as straight forward as it may sound - But perhaps it can be worth the effort in the long wrong instead of having to struggle with the potential limitations that can be encountered basing this on users instead of members.
I hope this can be used to perhaps approach building the intranet in another fashion perhaps.
/Jan
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.