We have upgraded to 6.5.2 from 6.1 on our development servers, and discovered that security is better enforced. Specifically, a user can no longer see folders and content items in Content Explorer unless his/her current community is the one that owns the item/folder.
We do accept that this is better enforcement, but it has consequences for us. Given the previous security implementation, we have for various reasons items and subfolders that are owned by communities other than those that own the folders in which they are located. Hence, it is impossible to navigate to, and edit, these, because the editor has to choose between a community with rights to see the item and a community with rights to get to the place from where it can be seen!
We are trying to understand to what degree the change is intentional, whether it is affected by any configuration settings, and what options we have to deal with the significant difficulties we would have in changing our approach.
I wish this (security lockdown) was mentioned in upgrade documentation! I nearly freaked out. Does this also mean that admin users need to be members of all communities to be able to get the full content view?
We have made some progress with this. We still think it’s a better implementation, but it needs to be documented by Percussion as part of the upgrade. At present this is what we believe to be the case:
If the Folder Community in Content Explorer is set to something other than “All communities”, this overrides the Folder ACL so that only members logged into the specific folder community will even see the folder. If you are a member of the community but you are currently logged into a different community then you won’t see it.
Otherwise (ie if the Folder Community is set to All Communities):
You can see a folder and its contents if you belong to one of the communities in the ACL on the Security tab
Assume that there are items that belong to community B, in a folder belonging to community A; you can browse to and therefore edit the items whilst logged into community B, so long as that community is in the folder ACL. This fixes our problem (which was that we restrict editing of navons by community, and of course each navon is therefore in a community different from that of the folder in which the navon is located).
You cannot view the folder or its contents if you do not belong to a community in the ACL, irrespective of whether you are currently logged into that community. This prevents users from wandering around the site; we had a particular issue because some of our content is access-controlled and should not be available to all editors.
If while logged into community B you create a subfolder of a folder that is owned by community A, it seems that, by default, the folder will be assigned to community A, not B. This is probably useful as it makes it difficult for editors (accidentally or not) to “hide” content from those responsible for supervising a community. The ACL can be changed after the folder has been created by those with the rights to do so, of course.
We have about 1000 folders assigned to specific communities instead of All, so the next step is to figure out whether we can use a script to fix that
This change was intentional. Prior to version 6.0 the folder’s community did control its visibility. There was a bug introduced into 6.0 that caused this security feature to stop working correctly, which we have fixed in version 6.5.1.
Please contact Percussion Technical Support for assistance in dealing with the change if you have not already done so.
Well the interesting thing is that all of a sudden “sharing” content seems to be…less than straight forward. For example, in terms of usability, we don’t want the end users to see all the other sites that are in the CMS (ie. under site folders, it should just show them their site).
However, with this you get the problem that you can’t search for any items on any other community (as you don’t have permission to navigate to that folder). Its almost as if you need a security setting that allows you search for items and find items within a particular folder if it is allowed.
Has anyone else run across this issue? Do you have a solution?
As Jay noted, the change was the result of a fix intended to restore functionality that was broken in the initial Version 6.0 release. We did not anticipate that customers would find this behavior acceptable and take advantage of it, so we did not document it. We have added a new item to the readme to address this issue. See the attached file (specifically, Item 41).
We have issued a patch for 6.5.2 that will allow you to revert to the less restrictive behavior and allow folders to be visible across communities regardless of their community setting (the acl will still apply).
By “will allow you to revert” do you mean it is now an option somewhere? Because it was my understanding that patches where cumulative and we wouldn’t want to install a patch for something else in a few months time, and find that communities no longer restrict access to folders, because this patch was included in the later patch.
Applying this patch or a later patch will not in and of itself change the behavior of folders with regards to folder visibility and communities.
The patch adds a setting in the server properties to allow those who were utilizing the less restrictive behavior continue to do so. If you apply this patch (or a later cummulative patch), you must also modify a setting in the server properties in order to revert to this less restrictive behavior.
If you apply this patch (or a later patch) but do not modify the server properties setting, then you will see no change in behavior - a folder’s community will continue to restrict its visibility only to those logged into that community.
We have applied this patch on 6.5.2, enabled “old style” Community Folder Visibility setting. However it seems that this doesn’t revert behaviour completely. In 6.0, new folder was saved with Folder Community equal to the community user was logged in when creating the folder. However, now “All Communities” is default.
That behavior was incorrect and was fixed as part of a different bug. The default community setting for new folders is “All Communities” by design. The patch specifically addresses the change in folder visibility encountered after upgrading.
