Grant membership to a UserGroup in all sites

[Cyril Fait, modificado 6 Anos atrás.]

As required by the client, we need to allow a user from a specific user group gets all possible search results within search functionality without grant admin user (users from this user group need to have read access to all sites/functionality, however, they cannot have access to control panel or edit content).
After investigating, we were able to conclude :
"Admin" user is able to view and edit any content across Liferay Portal, what makes a user with this role able to get all possible results for a search.
In order to make users whose don't have "Admin" role assigned able to get the same results in a search as an Admin user, would be needed to grant permission for every single site inside connect. Permission for a site is granted through site membership portlet and can be granted for users, user groups and organisations.
As assigning these memberships manually would be almost impossible, I've been working on an automated script which assigns one user group as a member of every site across Liferay platform. The Groovy script seems to be working fine (as data has been included into Liferay tables and when testing with few records search has worked as expected), however, when trying to use search functionality, am not getting any results (producing a final result even worse than before running the script).
It looks like a problem on Liferay when a User Group has many memberships assigned. My groovy code is as follows:

// Script to grant membership to a specific User Group across all sites of Liferay
import com.liferay.portal.service.GroupLocalServiceUtil
import com.liferay.portal.service.UserGroupLocalServiceUtil
 
out.println("Started!");
groupsCount = GroupLocalServiceUtil.getGroupsCount()
groups = GroupLocalServiceUtil.getGroups(0,groupsCount)
defaultGroup = UserGroupLocalServiceUtil.getUserGroup(10154, "MyUserGroup")
 
long[] defaulUserGroup = [defaultGroup.getUserGroupId()]
 
for (group in groups){
if (group.getType() > 1){
   if (!UserGroupLocalServiceUtil.hasGroupUserGroup(group.getGroupId(), defaultGroup.getUserGroupId())){
    UserGroupLocalServiceUtil.addGroupUserGroups(group.getGroupId(), defaulUserGroup)
   }
 }
}
 
out.println("Finished!");

I'm not sure if there is a better way to solve my problem, or if it's missing something in my code.

[Andrew Jardine, modificado 6 Anos atrás.]

Hi Cyril,

Your approach sound valid to me. A UserGroup called BigBrothers, then a bunch of users assigned to it, then assign the BigBrothers UserGroup to each site (group) in Liferay. The users who are assigned to the group will automatically become "Site Members" meaning any content that was created (as scoped as Site Member) will be revealed to them.

But this is also assuming that individual role permissions are not assigned to any documents. For example, let's say I add a document to the Document Library, and then set the VIEW permission on the document so that only users with the "Special Assignment" role are able to see it. In this case, even though the document is part of a site that the user group has been assigned to, unless the user group is given the "Special Assignment" role, users probably won't be able to see it.

So I think you approach is correct -- but these things are always hard to solve without the details. Can you share a little more about your hierarchy, the roles you have, etc? Maybe you can share with us a little more about what you are seeing as results?

[Cyril Fait, modificado 6 Anos atrás.]

I will try to explain better our scenario and the steps I have done so far :

- Most of the sites/documents don't have rules assigned for viewing.
- We have around 25000 private sites.

---> Initial scenario before running scripts
- If we log on within "test-admin" (user who has an admin role) and search for "xls", get 16 pages of result.
- If we log on within "test-user" (user without admin role) and search for "xls", get 1 page with 3 results.

After this initial scenario, I have identified some sites in "admin user" search results, and created a user group which have assigned a membership through the control panel.
Then assigned this user group to my "test-user". Finally have performed the search again and got a few more results as expected.

The next step was to automate the membership creation, to be sure, my script was working, have run it for a specific site:

import com.liferay.portal.service.UserGroupLocalServiceUtil
defaultGroup = UserGroupLocalServiceUtil.getUserGroup(10154, "My Group")
long[] defaulUserGroup = [defaultGroup.getUserGroupId()]
UserGroupLocalServiceUtil.addGroupUserGroups(18721, defaulUserGroup);

Again, the result was as expected, having a few more results returned on the search.

As final step, I have developed a script (on my first post), where tried to create a user group as a member of every private site in my portal, what should make search return all possible results. However, when trying to perform the search with "test-user", didn't get any result. If I remove the user group from this user and perform the search again, I get 3 results. So, it looks like my script is doing something wrong or Liferay not been able to handle this amount of data for a user group membership.

[Andrew Jardine, modificado 6 Anos atrás.]

Interesting, Ok -- I would say that your approach is sound and I myself probably would have done the exact same thing. So now to figure out why you can't get the results. My first thought is thinking about how big that query would be when the boolean clauses for 25000 sites are used. I know that there was (still is?) a property --

#
# Set the maximum number of clauses to allow in a boolean query. The default
# is 1024.
#
#lucene.boolean.query.clause.max.size=1024

Which is commented out by default and I am not even entirely sure if it is still applicable in 7. I don't know enough about ES to know for sure either if there are some defaults/limitations that can be overcome. This post seems to suggest that the query limit is actually the default in ES: http://grokbase.com/p/gg/elasticsearch/144cw662ay/query-string-length-limit

I wonder if you override that property in your portal-ext and give it something outrageous for a number like 100000 if it will return the results to you?

[Cyril Fait, modificado 6 Anos atrás.]

Ok, I was able to figure out why no results have been returned.
On Solr config file (solr-config.xml), there is a parameter related to max of boolean clauses:
<maxBooleanClauses>5120</maxBooleanClauses>
I changed this parameter value to 50120 and performed the search within my user group. Result was "almost" as expected - search has returned all results, however, if I just log in and try to search won't get any result, have to wait about 5-10 minutes, try again, and then get the expected results (I tried to log out and log in again, and the same behaviour happened again).
The final user probably won't be satisfied by this behaviour... So, I was wondering if there is some way of getting the same results as admin user from search and validate the permission only when user click on the result link.

PS: am using Liferay 6.1.20 with Solr

[Andrew Jardine, modificado 6 Anos atrás.]

Hey Cyril,

Maybe -- but I have some concerns with that approach. For starters, if you are using pagination, then you could end up getting a "page of records", none of which the user can access. I think it would make for poor UX.

Ideally I would like to understand what is happening in this 10 minute window during login, and why doesn't the admin account suffer the same affliction. The best answer I think would be to fix that issue. I am wondering if there is some background task that is running when the user logs in that is taking a long time to complete because of the 25000 site membership records. Maybe a thread dump after a user logs in will reveal something useful?

The other alternative might be to use a jso hook to alter the logic for the search portlet (I am assuming this is the "Search" portlet that comes out of the box you are referring to). You could update the JSP to alter the query, removing the the group filtering clause perhaps?

I would start with the thread dump though -- I bet something interesting comes out of it.