5

On a Content Publication - Is there anyway to hide the 'Default Templates' Folder and/or another sub-folder possibly called 'System' Folder under 'Building Blocks' from a folder permissions level?

For instance, I have a Content Authors Group that only wants to see the 'Content' folder under Building Blocks; however, it seems they need to have read/write access to the 'Systems' Folder because that is where we define the Schemas ('Content', 'Embedded', 'Metadata' etc) in a higher publication.

So I cannot set their permissions to be only read or null, because they need access to that folder in order to create a component and choose via the drop-down schema list associated with that content publication. Or is so how my troubleshooting is going..

I would have appended to this thread but my rep isnt high enough: Hide SDL Tridion sub Folder based on permissions

enter image description here

Improve this question
1
  • 1
    Yes, you can set different permissions for either Schema or the Schema's folders. I added a note to Bart's answer.
    – Alvin Reyes
    Commented Mar 19, 2015 at 20:33

2 Answers 2

Reset to default
7

To do this, first make sure that the "Hide organizational items if no access to content" setting is set to "1" in the Tridion Content Manager configuration ("General settings").

You can then remove Read permissions for the users on the root system folder, but grant it again on the sub-folders that they do need to access (e.g. Schemas). Since the system folder is hidden, the UI will not show it in the tree -- but the API will still allow them to read the Schemas within.

Improve this answer
3
  • nice one, that is actually solving it
    – Bart Koopman
    Commented Mar 20, 2015 at 12:11
  • Awesome! I made the changes per folder level like you said @Peter Kjaer and restarted the server and we are looking good!
    – Andy Ross
    Commented Mar 20, 2015 at 19:03
  • Viewer could still have read on System, as maybe the only group that has permissions on it.
    – Alvin Reyes
    Commented Mar 21, 2015 at 3:30
3

You can only hide Folders by denying read access to them for the given user/group.

A "System" Folder with Schemas in them cannot be hidden since the users need read access to that Folder else they cannot create Components based on it.

So the default system behavior is not going to help you here. The only option you have would be a UI extension, but since it will hide Folders which are intended to be shown I would recommend against that, as it might confuse people.

Improve this answer
4
  • Ok makes sense. It's just that the 'Content Authors' only want to see the pure 'Content' folders they will be working in, where other teams (system admins) are modifying the schemas and do not want to expose them to it at all..but I can understand it from a Tridion functionality perspective.
    – Andy Ross
    Commented Mar 19, 2015 at 19:50
  • 1
    Hiding works if you have the MMC snap in setting for hiding organizational items (set to 1). You can hide the System folder while removing the inherit permissions options on its Schema subfolder to give it Read (this is not localizing). You could even set different permissions for the folders inside the Schema folder. For example, everyone could safely have Read for Embedded Schemas.
    – Alvin Reyes
    Commented Mar 19, 2015 at 20:31
  • Ok. With a read permission on the 'System' folder, can the user still create components and see the schemas in the drop-down? And for this the MMC snap in setting is needed? noted here by Nuno tridion.stackexchange.com/questions/4061/…
    – Andy Ross
    Commented Mar 19, 2015 at 20:36
  • It'd be no permissions on the System folder (remove read), then read on Schemas folder or its subfolders. I was trying to help Bart adjust his answer, but @PeterK got it. ;-)
    – Alvin Reyes
    Commented Mar 21, 2015 at 3:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.