Granular permissions for dynamic content items - Feature Previews & Betas - Feature Previews & Betas - Progress Community
 Feature Previews & Betas

Granular permissions for dynamic content items

  • Granular permissions for dynamic content items
  • Dear Kali

     No nead on that for my small business clients.


  • Parent-Child is exactly how we'd use it mostly

     So like

    - Program
     -- Rotation

     We want to give the admins of each program access to *ONLY* their program...

     Would expect the permissions to flow down, right?... "inherit from parent" like everywhere else?

  • Hi all,

    We are starting work on “Granular permissions for dynamic content items” (for Modules created with the Module Builder).

    This feature will allow users working with dynamic content items in Sitefinity Backend, to set permissions on individual item level, much like this is done for the static modules now. The request on the Feedback portal can be seen here.

    We would be happy to hear your real cases and requirements in regards to this feature.
    Also, we are curious to learn if you are using content types in hierarchical (parent-child) relationships often in your projects. How do you expect permissions to be applied in such scenarios?

    We will be posting updates on the feature in this thread. You can subscribe and follow it for updates.

    Sitefinity Team

  • A real-world use-case I have is that I have built an API which exposes content items created with module builder to a mobile app. Before users can use the app they have to create an account on the website and they have to log into the app using these credentials. Thus, both the app and the server know their identities and can make decisions accordingly.

    A feature request that has come up several times already is that the client wants to restrict and expand the number of items that are returned to the app according to users' group memberships. Upon registration on the website all users are assigned to "Role A" using the built-in SF registration widget. Initially they get to see all public content items in the app that are returned by the API. However, if the editors manually assign a user to "Role B" in addition to "Role A" later on they should also be able to see content items restricted to "Role B" users.

    Regarding parent-child relationships: yes these are used frequently and I would expect authorization rules assigned to parents to be inherited by children with the option to have individual overrides as required.



  • Hi all,

    For the 7.3 release we are advancing with the implementation of granular permissions in dynamic content modules. That said, each dynamic content item now has its own Permissions section, where users can manage the permissions on individual item level.

    In addition to that we have extended the permissions API so that developers can implement custom permissions inheritance based on parent item (when content types are in hierarchy) or based on the value of a content item property (such as, associated tag).

    This is a video demonstrate how you can achieve inheritance of permissions from parent content items. It shows how, after a simple customization in the code, child items permissions (view/modify/delete) can be inherited from the modify permission of the parent content item.

    We have a few questions to you in regards to inheriting permissions form parent content items, which will help us develop further our sample:

    • If you have items in parent – child relationship, and you change the modify permission of the parent, do you expect that to reflect on the (view/modify/delete) permissions of all child content items created so far, or do you expect this to affect only the child items created from this moment on? Or, probably, we need to give you both options?
    • When you want to update the child item permissions once the parent item permissions are changed – do you need some child items to be skipped? In that case for selected child items the permissions will not be overridden by the parent permission change. Is there a case when you need to break the permissions of the child items or they should always be calculated based on the parent item permissions?

     Any other questions and comments are welcome.

    If you are interested to experiment we can deliver a preview build to test this feature.

    Sitefinity Team

  • I have an Intranet portal and I use the hierarchical relationship to group different links that belong to each of our applications. So mine is like Application -> Application Link. At the application level, I might have something like "Sitefinity Portal" and for the application links, they would be a set of links to things like "Sitefinity Documentation", "Sitefinity Production Website", "Sitefinity QA Website", "Sitefinity Project Plan", etc. There are some cases where a user should only be able to see some of the application links associated with an application they have permission to see. So I'll have a role that's something like "Sitefinity Administrator" and people assigned to that role could see all of the links and I'd have another role like "Sitefinity User" and those people could only see "Sitefinity Documentation" and "Sitefinity Production Website". Both "Sitefinity Administrator" and "Sitefinity User" would have permission on the "Sitefinity Portal" parent.

     To answer your questions:

    1. I would expect the default permission on the child to be the same as the parent, but have the ability to change the permissions on the child. If I change the parent permissions, I would like it to ask me if I'd like to apply this change to all of the children. In my case, I'm probably always going to say no to this, but there could be some cases where I do need to change all of the children and I'd like a fast way to do it without having to modify each child. Ideally, I would prefer 3 options: 1) Apply to all children. 2) Apply going forward. 3) Apply to children with the inherited permission ONLY (leaving alone any child permissions that do not match the current parent permissions)

    2. If I could not have the scenario described above, I would want any child that I've set custom permissions on to be skipped if I make changes to the parent. At that point, I have already broken the inheritance so there's probably a reason why I need it to be that way. 

  • I feel the same as shelly...although I would just want the children to literally inherit the parent, not physically break inheritance and apply the changes to the children (not sure if thats what you meant shelly)

     However yeah, it would be nice to have the option to wipe the child permissions instead of needing to open each individual one and fix them (since there's no way anywhere in the UI to see if an item has broken inheritance)

  • Just to be clear, I meant that if I had ALREADY broken the inheritance before making the change to the parent, I would want the children to stay as they are instead of changing to whatever the parent is being changed to. When creating a new child, I would always expect them to inherit from the parent, but to have the option of manually changing the permissions on each individual child record.
  • Hi all,

    And Steve and Shelly, and thanks for the helpful comments. We understand your scenarios and will try to incorporate them in the samples we design.

    As already announced, we have reworked the Permissions API so that it is very flexible and allows for easy customizations. In this video you can see how you can assign permissions to content items based on associated properties (in this case: category).

    Such functionality is useful when you want to make permissions dependent on certain parameters of the item.


  • This is amazing - been waiting for this feature for a long time! Thank you!

     Btw, any ideas when 7.3 is coming out?

  • Hey Kali....what will the backend grid look like?  Will it show everything with items you don't have access to greyed out, or will it just show the item you can edit?

     ...inline editing of an item you don't have access to edit also already handles, yeah?