Document Type / Element Type permissions (or hack)

Hi!

We’ve just started to work on a new solution that is going to host multiple “themed” sites in the same Umbraco instance. The idea is to have a set of “features” (blocks, documen types etc) and potentially use a subset of them for each “themed site”.

Each “themed site” is going to have different Users (and User Groups) with permissions for editors. For example, some editors might have access to control more than others. We’ve been playing with the new “Document Property Value permissions” which is awesome for this.

Now, one thing that we would really like to see is a way to hide “irrelevant” document types and blocks.

Examples:

  • A restricted editor might only be able to create a new “Block Page” and not new “Event Page”.
  • A site admin might be able to create both.

Or

  • “site 1” might have Block A, Block B and Block C, while we want to hide Block C for “site 2”.

I think I’m looking for something similar to “UI Write” and “UI Read” but on the Document Type level. I know about “Document permissions” but these are based on the tree, I’m looking for something similar for more like “Document Type permissions” on User / User Group level.

I’m aware that there are a lot of “ifs and buts”, e.g. like - what about “move”, “copy”, “duplicate” and so on, that could be used to “get around” this. But for this use case it would be fine with just hiding the option to create new doc types (and preferably blocks) based on the User permissions.

Have any one had a similar issue and found a decent solution that works in v17+?

Hi @markusjoha

@Luuk released an advanced permissions package not long ago, would something like that help/work for you?

Justin

Thanks @justin-nevitech !

I look at it and it seems like the use case that I have is not supported “out of the box” but the there are several useful and inspiring approaches.

@Luuk do you agree that my use case would not be supported or did I miss something?

@markusjoha no it’s not supported out of the box.

So if I get it right, you want the ‘create new’ insert options be dependent of the role. It’s probably not that hard to build, so I might try something tonight because this is on my to do list!

So do you agree that it is just a simple yes/no situation? So if you can set per document type on a user group: yes you can insert this or no, you can’t, that that would be enough?

@Luuk Yes, that would be the most important thing.

I was looking at the permission service in umbraco that you replace - thinking that maybe it would be possible to provide the same level of permissions (copy, move, etc) but based on the document type of the node and not the path in the tree?

I did not try anything yet.

I’ll have a look. I know it’s pretty easy to manipulate the ‘insert options’, so in my head that feature is really easy to do. The other things in your post are more complex and I don’t know if there are extension points for that. Interresting challenge though.

@Luuk insert options is more than enought. If you feel that it’s out of scope for the package (which i would understand) I would love to hear about your findings.

The insert options for the ‘create’ menu are very much doable, I intend to implement those very soon (maybe tonight if Claude is fast enough and I’m happy with the interface :P). I hope to provide a beta tonight.

Insert options for block lists are not doable without replacing parts of Umbraco, which I’m not keen on doing. There are no extension points for that.

And in the near future I intend to also make it possible for permissions, like ‘delete’ and ‘move’ to be set on document types as well and make them part of the resolver that determines the effective permissions, but that takes a little longer.

Waow! Looking forward to see what ever you and Claude come up with :slight_smile:

I figured that as well. I might try to buy someone from the core team a beer on CodeGarden and pitch ideas for extension points to facilitate that :rofl:

The problem is block list and block grid are completely isolated in a single property editor that a module of it’s own. That’s why there are not really extension points because in the end, it’s only a single component.

I’m thinking about rules for the insert option. If you have multi site, you would want to scope it. How complex would you say that is going to be? Would you only scope it to the root of a site (where cultures and hostnames are set), or would you say: this document type cannot be created on node A, but it can be created on it’s children, but not on it’s children children?

Yeah, that’s true but it would be nice if there was a way to filter the options listed by the grid when adding new blocks - I’ll have to think about that one and maybe come up with suggestions.

For my use case is “on/off” like “users from this groups should never see doc type X and Y”

I’m going to build you a beta version of the package tomorrow, it’s getting late. But this is the result. It’s probably much more granular than you need, but…why not, right?

I added an additional ‘Advanced document type permissions’ sidebar section. You select a role and document type (that’s still a bit of an ugly dropdown) and you can set ‘insert’ permissions. The insert permission if whether the document type will show up in the ‘create’ menu if it’s in there. It does not automatically add it to the create menu if it’s not set as an option on the document type.

So in your case, if you have a role and you just don’t want that document type visible at all for all users in the group, you just set the default permissions to deny and be done. But his granular control makes it possible to do this at the node level if you want to. This is especially handy if you have multiple sites in one instance; you can differ these permissions per site if you need to.

And just like with the content permissions, you can see what the effective insert options are for a given user group or user. Especially with users that have multiple groups, you can see the effective permission:

And the best part is that in the future, we could add additional permissions on the document type, like ‘delete’ or ‘move’. This way you can for instance set the ‘delete’ permission on the homepage to deny for everybody so that you are sure that no instance of a homepage document type can get deleted.

This looks awesome!!

I’ll show this to my team tomorrow and give it a spin when you are done with the beta, no rush at all :slight_smile:

Great stuff! :tada:

FYI, I started a discussion on GitHub to maybe find a way to add extension points that could be useful for the “hide blocks”-thing.

1 Like

It’s a beta, so it might have some rough edges. Let me know your toughts!

FYI, I just released 17.1.0:

Thanks @Luuk!

We’re still playing around with it :slight_smile: Will definitely make sure to give the beta a try as well.

// m

No need to use the beta, the changes are in v17.1.0 non beta now :slight_smile: