AjaxSearch and Document Groups (private_memgroup and private_webgroup)

128 Posts

Richard Reply #1, 17 years, 6 months ago

I am querying the logic when returning search results.

I have sites which have a private users area so certain documents are assigned to a web group.

When I am not logged in as a webuser the search returns results excluding any document assigned to the web group ... as expected.

However when logged in as a webuser via a frontend login the search returns ONLY results for documents in the web group. i.e. excluding all documents that are not in the web group.

Now I also have members groups (manager permissions) to restrict editing access for managers. Looking at the sql returned by ajaxsearch this seems to be my problem:

SELECT sc.id, sc.pagetitle, sc.longtitle, sc.description, sc.alias, sc.introtext, sc.menutitle, sc.content, sc.publishedon, 
GROUP_CONCAT( DISTINCT CAST(ntv.id AS CHAR) SEPARATOR "," ) AS tv_id, 
GROUP_CONCAT( DISTINCT ntv.value SEPARATOR ", " ) AS tv_value 
FROM `modx_site_content` sc 
LEFT JOIN `modx_document_groups` dg ON sc.id = dg.document 
LEFT JOIN( 
SELECT DISTINCT tv.id, tv.value, tv.contentid 
FROM `modx_site_tmplvar_contentvalues` tv 
WHERE (((tv.value LIKE '%golf%'))) ) AS ntv ON sc.id = ntv.contentid 
WHERE ((sc.published=1) AND (sc.searchable=1) AND (sc.deleted=0) AND (sc.type='document') AND (ISNULL(dg.document_group) OR (dg.document_group IN (1,6)))) 
GROUP BY sc.id 
HAVING (((sc.pagetitle LIKE '%golf%') OR (sc.longtitle LIKE '%golf%') OR (sc.description LIKE '%golf%') OR (sc.alias LIKE '%golf%') OR (sc.introtext LIKE '%golf%') OR (sc.menutitle LIKE '%golf%') OR (sc.content LIKE '%golf%') OR (tv_value LIKE '%golf%'))) 
ORDER BY sc.publishedon,sc.pagetitle

The WHERE clause is checking for ISNULL(dg.document_group) to pick up docs which are not in a web group. But for me this is not null for those documents not in a web group (user permissions) as they are also part of a members group (manager permissions).

Bottom line is should this SQL statement be taking the private_memgroup and private_webgroup flags into account in the documentgroup_names table or have I missed a snippet parameter that can help me out?

Thanks, Richard

1,717 Posts

coroico Reply #2, 17 years, 6 months ago

When I am not logged in as a webuser the search returns results excluding any document assigned to the web group ... as expected.

OK

However when logged in as a webuser via a frontend login the search returns ONLY results for documents in the web group. i.e. excluding all documents that are not in the web group.

Are you sure ? Go on this page, search for "proud", note the number of results (you get the document #63) and then go to the login page (enter the informations twice if you get a message regarding the security code), and then redo the search with "proud". You get 3 results (the public document #63 and the private documents of the group #1 and group #2)
The results includes all the documents, even those which are not in the group #1and group #2

The WHERE clause is checking for ISNULL(dg.document_group) to pick up docs which are not in a web group. But for me this is not null for those documents not in a web group (user permissions) as they are also part of a members group (manager permissions).

did you try to link your manager_group wth the same document_group as the web_group ?

128 Posts

Richard Reply #3, 17 years, 6 months ago

thanks for relying coroico

I see your example works just fine. I tried linking the manager group but it did not help. It is not specifically managers that have the problem. Anyone does logging in as a web user.
Can I ask what security premissions you have against your #63 doc on the test page, does it have a manager permission set to make Manager access: Private ?

For example. If I have a document that is:
Web access: Public
Manager access: Public

Then I can search for it both logged in as a web user or not... obviously.

However. If the same document is set as:
Web access: Public
Manager access: Private

I can then search for it when not logged in as a web user, but when I am it does not return the search. So adding a manager security group is messing up the returned docs.

1,717 Posts

coroico Reply #4, 17 years, 6 months ago

Can I ask what security premissions you have against your #63 doc on the test page, does it have a manager permission set to make Manager access: Private ?

The document #63 is public. and documents #68 belongs to the "asDocGrp1" group document and the document #73 belongs to the "asDocGrp2" group document.

the asearch web user belongs to the "web" web user group. And the "web" web user group has an access to the "asDocGrp1" and "asDocGrp2 group documents. So when you are logged as "asearch" on the demo site, you could access to the documents #68 and #73.

Documents #63 and #73 haven’t any manager user permissions.

However. If the same document is set as:
Web access: Public
Manager access: Private

I can then search for it when not logged in as a web user, but when I am it does not return the search.

What ’s the meaning of Manager access: Private ?

Your document could be linked to a document group. And then a document group gather a list of documents.
And in the other hand, a user could be a web user who belongs to a web user group OR a manager user who belongs to a manager user group.

And finally you could link a document group to a manager user group or a web user group.

128 Posts

Richard Reply #5, 17 years, 6 months ago

Documents #63 and #73 haven’t any manager user permissions.

That is the difference and that is the meaning of ’Manager access: Private’. If you add a document to a manager permission then it shows as ’Manager access: Private ’ in the document ’page data’ in the right hand window pane when selecting the document from the document tree.

This relates back to my first post with the sql. As both manager and user document groups are stored in the same table (document_groups) then the ISNULL(dg.document_group) test will currently pick up both manager groups and user groups. So if the document in question is a member of a manager group it will not be null, even if it is not part of a web user group.... and hence is not returned as a search result. This is where the documentgroup_names table comes in as it has flags ’private_memgroup’ and ’private_webgroup’ to differentiate these two.

I suspect if you give your document #63 a manager user permission to make it ’Manager access: private’ (but leave with no web user access... so still ’Web access:public’) you may see the same behaviour I see?!

The behaviour problem I see really relates to a document that has a manager user permission set in conjunction with a user logging in as a web user... there is no issue with the web user permissions as such, just the manager user permissions not being ignored when the web user is logged in.

1,717 Posts

coroico Reply #6, 17 years, 6 months ago

I have changed the demo site by adding the document #64 into a "admDocGrp". So now the document #64 exists in the table document_groups.
So we have the following context:

#64 : public document

webUser ---webGroup=========== WebGrpDoc --------- Doc

asearch ----- web============== asGrpDoc1 --------- 68
asearch ----- web ============== asGrpDoc2 --------- 73

id of asGrpDoc1 = 1 and asGrpDoc2 = 2

mngUser ---mngGroup=========== mngGrpDoc --------- Doc

admin1 ----- admin============= admGrpDoc --------- 64

id of admGrpDoc = 4

All these documents have search terms "proud".

The current results with 1.8.1 release are:
case 1/ When logged as a web user (asearch): you got the documents #63 (public) and #68 and #73 (webGrpDoc)
case 2/ when you are not logged, you get #63 (public) AND #64 (mngGrpDoc)

From my point of view, results of the case 1 are correct. When you are logged as web user you are not logged as manager user. So you can’t get the #64
the select is:

SELECT sc.id, sc.pagetitle, sc.longtitle, sc.description, sc.alias, sc.introtext, sc.menutitle, sc.content, sc.publishedon, 
GROUP_CONCAT( DISTINCT CAST(ntv.id AS CHAR) SEPARATOR "," ) AS tv_id, 
GROUP_CONCAT( DISTINCT ntv.value SEPARATOR ", " ) AS tv_value 
FROM `mod2_site_content` sc 
LEFT JOIN `mod2_document_groups` dg ON sc.id = dg.document 
LEFT JOIN( 
SELECT DISTINCT tv.id, tv.value, tv.contentid 
FROM `mod2_site_tmplvar_contentvalues` tv 
WHERE (((tv.value LIKE '%proud%'))) ) AS ntv ON sc.id = ntv.contentid 
WHERE ((sc.id IN (63,308,64,65,66,67,68,69,70,71,72,73,97)) AND (sc.published=1) AND (sc.searchable=1) AND (sc.deleted=0) AND (sc.type='document') AND (ISNULL(dg.document_group) OR (dg.document_group IN (1,2)))) 
GROUP BY sc.id 
HAVING (((sc.pagetitle LIKE '%proud%') OR (sc.longtitle LIKE '%proud%') OR (sc.description LIKE '%proud%') OR (sc.alias LIKE '%proud%') OR (sc.introtext LIKE '%proud%') OR (sc.menutitle LIKE '%proud%') OR (sc.content LIKE '%proud%') OR (tv_value LIKE '%proud%'))) 
ORDER BY sc.publishedon,sc.pagetitle

To get the #64 document from the admGrpDoc document group you are obliged to link the admGrpDoc to the "web" web user group:

asearch ----- web============== admGrpDoc --------- 64

With this new link you get the four results: #63 (public), #64 (admDocGrp) and #68 & #73

select statement:

SELECT sc.id, sc.pagetitle, sc.longtitle, sc.description, sc.alias, sc.introtext, sc.menutitle, sc.content, sc.publishedon, 
GROUP_CONCAT( DISTINCT CAST(ntv.id AS CHAR) SEPARATOR "," ) AS tv_id, 
GROUP_CONCAT( DISTINCT ntv.value SEPARATOR ", " ) AS tv_value 
FROM `mod2_site_content` sc 
LEFT JOIN `mod2_document_groups` dg ON sc.id = dg.document 
LEFT JOIN( 
SELECT DISTINCT tv.id, tv.value, tv.contentid 
FROM `mod2_site_tmplvar_contentvalues` tv 
WHERE (((tv.value LIKE '%proud%'))) ) AS ntv ON sc.id = ntv.contentid 
WHERE ((sc.id IN (63,308,64,65,66,67,68,69,70,71,72,73,97)) AND (sc.published=1) AND (sc.searchable=1) AND (sc.deleted=0) AND (sc.type='document') AND (ISNULL(dg.document_group) OR (dg.document_group IN (1,2,4)))) 
GROUP BY sc.id 
HAVING (((sc.pagetitle LIKE '%proud%') OR (sc.longtitle LIKE '%proud%') OR (sc.description LIKE '%proud%') OR (sc.alias LIKE '%proud%') OR (sc.introtext LIKE '%proud%') OR (sc.menutitle LIKE '%proud%') OR (sc.content LIKE '%proud%') OR (tv_value LIKE '%proud%'))) 
ORDER BY sc.publishedon,sc.pagetitle

Case 2
The results are not correct. When you are not logged, you shouldn’t get the document #64 as result. This is an issue.
This issue is due to the fact that, when the user is not logged, I don’t check that the document is or not in the documents_group table.
This is clearly an issue.
Here is the select statement:

SELECT sc.id, sc.pagetitle, sc.longtitle, sc.description, sc.alias, sc.introtext, sc.menutitle, sc.content, sc.publishedon, 
GROUP_CONCAT( DISTINCT CAST(ntv.id AS CHAR) SEPARATOR "," ) AS tv_id, 
GROUP_CONCAT( DISTINCT ntv.value SEPARATOR ", " ) AS tv_value 
FROM `mod2_site_content` sc 
LEFT JOIN( 
SELECT DISTINCT tv.id, tv.value, tv.contentid 
FROM `mod2_site_tmplvar_contentvalues` tv 
WHERE (((tv.value LIKE '%proud%'))) ) AS ntv ON sc.id = ntv.contentid 
WHERE ((sc.id IN (63,308,64,65,66,67,68,69,70,71,72,73,97)) AND (sc.published=1) AND (sc.searchable=1) AND (sc.deleted=0) AND (sc.type='document') AND (sc.privateweb=0)) 
GROUP BY sc.id 
HAVING (((sc.pagetitle LIKE '%proud%') OR (sc.longtitle LIKE '%proud%') OR (sc.description LIKE '%proud%') OR (sc.alias LIKE '%proud%') OR (sc.introtext LIKE '%proud%') OR (sc.menutitle LIKE '%proud%') OR (sc.content LIKE '%proud%') OR (tv_value LIKE '%proud%'))) 
ORDER BY sc.publishedon,sc.pagetitle

I have remove the link between admDocGrp and the "web" web user group. So you can run these examples on this demo page

Thanks a lot for this important feedback

128 Posts

Richard Reply #7, 17 years, 6 months ago

From my point of view, results of the case 1 are correct. When you are logged as web user you are not logged as manager user. So you can’t get the #64

I don’t see how case 1 can be considered correct. If you are logged in as a web user and not as a manger the MODx system still allows you to see the website page #64! Manager security is for backend site management not frontend security? As a web user it is irrelevant which managers are assigned to administer which documents I should (and can using MODx security logic) view the page #64 when logged in or not as a web user:

http://www.modx.wangba.fr/index.php?id=64

so a search should return results for it.

And hence I see case 2 as correct!

1,717 Posts

coroico Reply #8, 17 years, 6 months ago

Do you agree that if you have a document group named "docGrp", any document which belongs to this document group is private as soon as a user group is linked to this document group.

Do the test, but if the user group is defined as a manager user group, this means that the document are allowed to users that are logged to the backend.
And if the user group is defined as a web user group, this means that the document are allowed to users that are logged to the frontend.

And logged as web user don’t implied to access to the documents thru the backend and logged as manager user do not implied to access to documents thru the front end.

See http://svn.modxcms.com/docs/display/MODx096/Why+Manager+Users%2C+Roles+and+Groups

128 Posts

Richard Reply #9, 17 years, 6 months ago

Do you agree that if you have a document group named "docGrp", any document which belongs to this document group is private as soon as a user group is linked to this document group.

Yes as long as by private you mean ’Web access: Private’

I have followed your test and it funtions as you explain, I just don’t think your logic is correct.

Do the test, but if the user group is defined as a manager user group, this means that the document are allowed to users that are logged to the backend.

... but the document with ONLY a manager user group is defined as ’Web access: Public’ still. So should be searchable from the fronend as you can still access the page from the fronend.

This next bit is key to the logic: You have doc #64 assigned to a manager group now, so by your logic I should not be able to visit this document page on your website... but I can:
http://www.modx.wangba.fr/index.php?id=64 ... this page is visible to anyone regardless of if they are logged in to a manager or user account.... as it shoud be because you have only set manager access.

To me this is because it is ’Manager access: Private’, i.e. when managing the website from the backend only certain managers can access/edit the document. Whereas is is still ’Web access: Public’ so anyone visiting the site can still see the document. It would be a bit odd to have the visibility of a frontend website document dictated by which managers can edit the document in the backend.

My scenareo:
I have different manager groups assigned to various documents so I can restrict the editing of these documents via the backend. I still want all visitors to the site to see these documents (whether they are logged in as a web user or not). Hence the document is left as ’Web access: public’.. i.e. no web user group assigned. This works as expected, but the search does not honour this MODx logic.

See http://svn.modxcms.com/docs/display/MODx096/Why+Manager+Users%2C+Roles+and+Groups

yes, but the key line here is "to control access to the documents in the Document Tree". We are not talking about the document tree in the manager we are talking web pages on the frontend.

1,717 Posts

coroico Reply #10, 17 years, 6 months ago

This next bit is key to the logic: You have doc #64 assigned to a manager group now, so by your logic I should not be able to visit this document page on your website... but I can:
http://www.modx.wangba.fr/index.php?id=64 ... this page is visible to anyone regardless of if they are logged in to a manager or user account.... as it shoud be because you have only set manager access.

I have remove the link between admDocGrp and the "web" web user group. So you can run these examples on this demo page

You can run these examples BUT as I have removed the link between admDocGrp and the "web" web user group, it is normal that you see the #64 document.

Read this line and in few minutes, I put in place again the link and you will see the difference.