Document Library folder permissions are not exporting/importing for Administrators/Owners.

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 6.0.5 GA, 6.0.6 GA
• Fix Version/s: 6.0.12 EE, 6.1.0 CE RC1
• Component/s: Administration > Roles & Permissions, DM > Document Library Display
• Labels:
  • QA-R
• Environment: Tomcat 6.0.29 + MySQL. Firefox 3.6.13. 6.0.x Revision: 77027. ; Tomcat 6.0.29 + MySQL. Firefox 3.6.13. 6.1.x Revision: 77027.
• Branch Version/s:
  6.0.x
• Backported to Branch:
  Committed
• Similar Issues: Show 3 results ; ;

  LPS-30218	Version Historys are not exported/imported
  LPS-27950	Document library toolbar does not respect folder permissions
  LPS-2205	Document library files do not inherit permissions of folder

1. Create a site template with 1 page and place Document Library portlet on page with 1 folder.
2. Set permissions on portlet and folder to grant owner, Community Administrator and Community Owner full rights.
3. Create new community using site template above as private pages
4. Inspect the permissions on the Document Library portlet in the target community and the Community Administrator and Community Owner roles are missing.

See attached image for views of the permissions.

Also, same behavior observed if simply using the portlet export/import facility.

[James Denmark]

Did another test eliminating MySQL to eliminate problems with the db init routines but exactly same behavior using the bundled HSQL db.

[Cynthia Wilburn]

Updating affected version from 6.0.5 to 6.0.6. Key issues that were closed in 6.0.6 are in the 6.0.6 release notes.

[Pani Gui]

Can reproduce in 6.0.x and trunk (revision:77027) Tomcat + MySQL.
The permissions for Community Administrator and Community Owner and Community Member are lost when using the site template to create a public page or a private page to a community.
Thanks for your report.

[Juan G]

This issue is a backlog candidate for the 100 PaperCuts program. Please consider participating! See http://liferay.com/community/100-papercuts

[Juan G]

This issue is currently being addressed in Sprint 4 of the 100 PaperCuts program. Please see http://liferay.com/community/100-papercuts

[Juan G]

Hi James,

I'll write down all my findings about this.

First of all, these issue is not reproducible when changing scope to non-default (page scope for example).

Here are the lines that are causing that roles not to be appearing in permissions (in case of permissions algorithm 6):

http://svn.liferay.com/browse/portal/trunk/portal-web/docroot/html/portlet/portlet_configuration/edit_permissions_algorithm_5_to_6.jsp?r=80320#l167

It's so clear in source code that those roles (community/organization admin and owner) shouldn't appear in role list when scope is organization or community.

After digging into SVN revisions, I found that those lines were added in SVN revision 30796:

http://svn.liferay.com/changelog/portal/?cs=30796#trunkZ002fportal-webZ002fdocrootZ002fhtmlZ002fportletZ002fportlet_configurationZ002fedit_permissions_algorithm_5_to_6.jsp

that was part of this issue:

http://issues.liferay.com/browse/LPS-3193

Wow! This came from 5.2.3 version so I guess someone from Liferay staff can tell us if changing this conditions in source code would break something or not. I will send an email.

What do you think, James?

[James Falkner]

So, I was able to reproduce this with a build from a couple of days ago but I think Jorge must have fixed it because I don't see the bug anymore with today's code. I am able to set permissions for "Community Member" during template creation, and these permissions are preserved when I create a new Site based on the template.

Juan, please try again using the latest code.

One thing I did notice is the disappearing roles (Community Admin/Owner). I believe these roles should not be shown at all in the template, and the code in edit_permissions_algorithm_5_to_6.jsp is not taking into account the fact that it can be used when editing a template (vs. a live site).

[James Denmark]

So now I am a little more confused. If the community owner and admin roles are being eliminated from the permissions panes.... Then how are we supposed to set these permissions at all? I was using these roles to give my community managers different permissions than regular community owners.... Confused...

[James Denmark]

I can't edit my previous comment - the last sentence should read - I am using these roles to give my community managers different permissions than regular community members. Can you explain why Algorithm 6 either doesn't require them or at least won't permit changing them?

It seems to me that LPS-3193 was just about showing them greyed out although it also suggests that setting the permissions on a group scoped role like community/organization owner/admin isn't something that can be done at the group level - which seems counter-intuitive to scoping them at all...

I guess what I am really missing is why algorithm 6 doesn't support these roles when algorithm 5 did - seems like a significant change in design for something that was supposed to just be a performance improvement.

[Jorge Ferrer]

Hi James et al,

The Community Owner and Community Admin roles are special roles that have all permissions by default. There is no need to assign explicit permissions because the permission system uses shortcuts for performance and won't even check them.

That's the reason why the UI doesn't show those roles, they already have all permissions and you won't be able to remove them (and administrator of a community wouldn't want a user to put something in the community and hide it from him, right?)

Considering this, I'm not sure if there is a bug here or not. What's exactly the issue you experience when exporting/importing?

[Juan G]

Hi James,

It seems permissions for those roles can't be modified at all when scope is default (always will have permissions if portlet belongs to the organization/community).

So IMHO this issue doesn't exist. Perhaps solution could be to change that portlet scope to non-default or change role for that.

What do you think?

[James Denmark]

Thanks for the explanation Jorge, that makes sense.

My use case for restricting this was to prevent admins/owners from changing the folder structure we provide in the community templates. That way only the omniadmin could do that. Sounds like I need to create a more restricted community manager role that still has the rights to make announcements, accept/deny membership requests, add portlets etc.

Presumably the ability to set the these permissions in the site template is still an outstanding bug?

Also, changing a portlet to page scope is allowing the admin/owner permissions to be changed. Also a bug?

The main issue still requires a solution: not carrying over the more restricted member permissions settings from the site template.

Also see http://issues.liferay.com/browse/LPS-17683 for another issue with page scoped permissions and teams.

[Jorge Ferrer]

Hi James, Juan,

I've just committed a fix to trunk (r82023) that makes the portal properly hide those administrator roles from all resources to avoid the confusion. I'm marking the ticket as resolved.

[Michael Saechang]

PASSED Manual Testing using the following steps:

1. Add Document Library Portlet.
2. Add Folder.
3. Edit permissions for folder.
4. Verify that Community Admin and Community Owner no longer appears.

Fixed on:
Tomcat 6.0 + MySQL 5. Firefox 3.6.16. 6.0.x Revision 83034.
Tomcat 6.0 + MySQL 5. Firefox 3.6.16. 6.1.x Revision 83069.