HowTo: Hide the Content Types and Content Parts dashboard menu items for some users and show them for other users?

Topics: Administration, Customizing Orchard
Apr 29, 2013 at 1:41 AM
Hi there,

We are trying to understand the Orchard request life cycle by reading this blog post by Bertrand Le Roy. We became confused during the third paragraph and asked a question on Stack Overflow. We would like to be able to step through the code that creates the Layout shape.

Cheers,
Shaun
Coordinator
Apr 29, 2013 at 2:09 AM
Edited Apr 29, 2013 at 2:09 AM
It's created by the work context the first time it's needed (look at the Layout property accessor there). More importantly, why does it matter to you? Are you just trying to understand Orchard, or do you need it for something specific? Shapes in Orchard are created on-demand as needed, and in general it doesn't matter much who does so first. For example, you may create a zone shape as a side effect of adding a shape into it. When you do it, you do not care if the shape already exists. If it doesn't, it will just get created.
Apr 29, 2013 at 3:48 AM
Edited Apr 29, 2013 at 3:50 AM
Hi Bertrand,

Thank you for that. I appreciate that you took the time to answer here and on SO. I found the code to which you referred me.
public dynamic Layout {
    get { return GetState<object>("Layout"); }
    set { SetState("Layout", value); }
}
Why does it matter to me? It helps me to understand the request life cycle, which in turn helps me to customize Orchard. The specific customization I am attempting is an admin dashboard with limited access. I asked about this on SO, but I think the question is too broad or inappropriate in some other way, which is fair enough, as it keeps SO sharp.

It's interesting that you write that the order of shape creation isn't important. If it doesn't matter when a shape is created, then does it matter when a shape is removed? How do we prevent a shape from being created?

What I want to do is to remove some menu items (and other content items) from the dashboard for certain users. The problem is that existing permission sets do not cover my requirement: I want a permission that lets a Dealer (new Role) view all content items on the front end but view only content items they own on the dashboard. Further, I want to remove the ContentType and ContentPart menu items from the Dashboard for Dealers (this is another new permission, maybe). Here are some possible strategies up with which I have come, most of which assume that the order of shape creation is important.

Where to add the code to filter out menu items:
  1. In Orchard.Core
  2. In a Module (this seems best)
  3. In a Theme
When in the request life cycle to filter out some menu items:
  1. before menu item retreival
  2. During menu item retrieval
  3. After menu item retrieval
  4. Before rending the menu
  5. After rendering the menu (e.g. JavaScript)
On what property to filter out some menu items:
  1. Menu item name via string comparison
  2. Menu item permission (requires a new permission)
  3. Menu item boolean flag (requires adding a new content field to menu items).
That is the best that I can do, for now, to explain why the life cycle and thus the Layout creation matters to me. I imagine my strategies betray that I don't quite understand how Orchard works.

Thank you again for taking the time to respond. I am looking forward to contributing to The Orchard Project and specifically to contributing documentation as I develop.

Cheers.
Shaun
Coordinator
Apr 29, 2013 at 4:55 AM
You can't really prevent a shape from being created: Orchard is a collaborative environment where many agents can chime in for pretty much anything. What you can do however is catch a shape early enough that it's creation is harmless, and send it to oblivion. The right place to do that is a shape table provider. There are events that you can define in there to catch shapes and move them to a zone that will never get rendered for example, or empty it, or change the shape to something else, or whatever you want. I'd encourage you to check out existing shape table providers to get familiar with the sort of thing you can do from there. I have a couple of blog posts on that by the way.

For menu items, know that you can easily create your own menu item types (see David Hayden's blog post on the subject). I'd recommend that, as you'll probably want to leave some menu items alone, and keep them as fast as possible: on-the-fly permission checking can be quite expensive. This way, you are in control of when the items display.
Apr 29, 2013 at 5:40 AM
Edited Apr 29, 2013 at 6:57 PM
Hi Bertrand,

Thank you for the response. You can imagine my enthusiasm for learning about shape table providers!

I will check out some existing shape table providers and look at your related blog posts.

About menu items, you wrote:
you can easily create your own menu item types
  • I am not sure how this helps me.
  • How can this contribute to preventing certain users from viewing certain menu items?
  • Don't we hide menu items (send them into oblivion) with the shape table provider?
you'll probably want to leave some menu items alone
  • What does it mean to leave some menu items alone?
  • Eg. Does it mean don't hide them / send them into oblivion?
  • Does that mean that I won't want to leverage / to hide the existing menu items?
on-the-fly permission checking can be quite expensive
  • Good to know. It sounds like that option is out, then.
This way, you are in control of when the items display.
  • Hmm. Where does this leave me in regard to hiding certain menu items from certain users?
  • It sounds like I can have control of only when my own menu item types display.
  • What, though, about controlling the display of built in menu items? That is what I really want to achieve.
We have end users in a Dealer role who will be viewing the dashboard. To prevent confusion, we want to let them view only menu items that are relevant to them, and to hide all the rest of the menu items. I am not sure how creating custom menu items types and leaving existing menu items alone helps us there.

Here is an image that approximates what we are trying to achieve:

Image

Thank you again for the help Bertrand.

Cheers,
Shaun
Coordinator
Apr 29, 2013 at 5:48 AM
You didn't say that you wanted to hide admin menu items. That is quite different. Why are permissions not working for this?
Apr 29, 2013 at 4:40 PM
Edited Apr 29, 2013 at 6:57 PM
Hi Bertrand,

Yes. Admin is an important part, that I left out.

The current permissions, as far as I can tell, do not enable hiding the Content menu item from certain users. Further, and most importantly, they do not appear to let us hide the Content Types nor Content Parts sub menu items.

We do not want users in the Dealer role to be able to create new Content Types nor Content Parts (although we do want them to be able to Create a specific subset of content items called Products, and to Read, Update, and Delete content items that they own, but that might be another question). Therein lies the problem.

How do we hide the blue admin menu items on the dashboard for users in the Dealer role?

Image

Thank you again, Bertrand, for the time that you are spending on this discussion.

Cheers.
Shaun
Coordinator
Apr 29, 2013 at 6:15 PM
Yes they do. Each module can and should verify permissions as they are adding admin menu items. Not granting those permissions will make the menu items go away. If you do not grant the "Edit Content Type" permission, users won't be able to create and edit content types and parts. You also have specific permissions for each content type.
Apr 29, 2013 at 10:00 PM
Edited Apr 29, 2013 at 10:13 PM
Hi Bertrand,

Thank you again for your replies. The solution that you gave didn't help, though.

Not granting permissions for the Content Types and Content Parts menu items didn't make those menu items go away. We did not grant "Edit Content Type" permission to the Dealer role, and the Content Types and Content Parts menu items still show up in the dashboard. Now, when Dealers try to create and edit content types and parts they receive a permission denied message. This is good. That said, we want to go further and make the Content Types and Content parts menu items go away.

Here are the steps that we took:
  1. Login as admin.
  2. Go to Dashboard > Users > Roles > Dealer (a new role we created)
  3. Allow the Dealer to Access admin panel
  4. Ensure that Allow is not selected for Edit content types.
  5. Save.
  6. Logout as admin, login as a Dealer.
  7. Go to Dashboard > Content.
  8. Unfortunately, the Content Types and Content Parts sub-menus are present.
Image

We then continued by trying to create a new content type as a Dealer.
  1. Click on Content Types.
  2. Click on Create new content type.
  3. The following web page opens, which indicates that Dealers cannot create new content types.
Image

It's good that, when a Dealer tries to create a new content type, Orchard denies access. We want to go further than this, though, and prevent Dealers from even trying. That means hiding the menu options. Is there a built in way to do that?

Cheers.
Shaun
Coordinator
Apr 29, 2013 at 10:20 PM
This has already been fixed in 1.x
Apr 29, 2013 at 10:26 PM
Edited Apr 29, 2013 at 10:46 PM
The bottom right corner of the dashboard says, "Orchard v.1.6.0.0." Do we need to do something else to upgrade to 1.x?

We just tried doing a fresh pull of Orchard from Mercurial and are seeing the same behavior. Are we missing some part of the process?
Coordinator
Apr 30, 2013 at 1:01 AM
You need to pull from the 1.x branch, not the default branch.
Apr 30, 2013 at 2:13 AM
Edited Apr 30, 2013 at 7:28 PM
Thank you! I pulled from the 1.x tip. It worked perfectly.

Image