We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 5811
    • 1,717 Posts
    Now I have added the link admDocGrp <--> "web" web user group.

    So now you can’t access to the page #64 without be logged as a "web" user.
      • 31178
      • 128 Posts
      yes. that works. But that is not the scenario I am querying. It is when the document has no web group assigned and just a manager group that is the problem combination.

      When it is not in a web access group as it was before and just in a manager access group you could see document #64 from the front end... as expected. Do you agree? ... which is because the document becomes ’Web access: Public’ we just have a manager group assigned for setting access for backend management ’Manager access: Private’.
      In this case your search should return results for #64 as you can see the document on the frontend website. Currently it does not.

      If I am wrong on this I will humbley apologize for wasting our time, but at the moment I really want to persue this to sort it out...  smiley
        • 5811
        • 1,717 Posts
        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.
        The error come from this part of the sql statement:
        AND (sc.privateweb=0)

        I need to test sc.privatemgr field too >:(

        So for a quick fix of this issue, replace classes/search.class.inc.php code:
                    // documents should be public
                    $this->main['filters'][] = array(
                        'field' => 'privateweb',
                        'oper' => '=',
                        'value' => '0'  
                    );

        by
                    // documents should be public
                    $this->main['filters'][] = array(
                        'field' => 'privateweb',
                        'oper' => '=',
                        'value' => '0'  
                    );
                    $this->main['filters'][] = array(
                        'field' => 'privatemgr',
                        'oper' => '=',
                        'value' => '0'  
                    );


        To conclude, I have change the doc #70 (added proud in the text) and link this document with a new manager group doc "admDocGrp2".
        The admDocGrp2 is not linked to the "web" web user group.

        I have fixed the release 1.8.2 with the above fix. So you could see the difference now between the release 1.8.1 and 1.8.2.
        Search "proud" . You get 2 results with 1.8.1 (one wrong because linked to a manager group) and only 1 (the public) with 1.8.2

        I give you some time to see the difference and then I will come back to the original documents (without "proud" on page) and original permissions.
        Again, thks for your feedback. I will registered this issue and provide the correction with the 1.8.2

          • 31178
          • 128 Posts
          I dont see ’proud’ in doc 70... and I always get 3 docs returned (#63, #73, #68) from the search in 1.8.1 and 1.8.2

          I still think you have the logic the wrong way round. i.e Case 1 was not correct and Case 2 was correct.

          Case 2 should have return #64 when it has a manager only premission assigned as it is still ’Web access: Public. If you navigate to the page when not logged in you can see the page: http://www.modx.wangba.fr/index.php?id=64

          so why should you not be able to search for it?
            • 5811
            • 1,717 Posts
            I have coming back to the original documents and permissions.
            Not sure that everybody could follow all the posts below. So, I will try to summarize:

            The context of the permission pages is the following:

            #63 : public document

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

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



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

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

            With AjaxSearch 1.8.1the search of the term "proud"

            - when a user is not logged provides the document #63 (public) and #64 (mngGrpDoc).
            It is not normal to get the doc #64 - This issue is now corrected with AjaxSearch 1.8.2

            - when you are logged as "asearch" who belongs to the "web" web user group, the search provides the documents #64, #68 and #73.
            This result is normal. When you are logged as a web user, you access to the public documents + the documents which belongs to your linked group documents. Here: asGrpDoc1 and asGrpDoc2, so we get #68 and #73.
            Doc #73 is excluded because it doesn’t belong to one of document group linked with the user logged as "asearch".

            - If you are logged as "admin1", you will get #63 and #73. Not #68 and #73.



              • 31178
              • 128 Posts
              when a user is not logged provides the document #63 (public) and #64 (mngGrpDoc).
              It is not normal to get the doc #64 - This issue is now corrected with AjaxSearch 1.8.2
              This IS normal. #64 is restricted for the manager interface it is not be restricted for the website interface.

              Could you confirm for me, when not using the search and not logged in that you cannot access the following link?... you should be able to.
              http://www.modx.wangba.fr/index.php?id=64 ... to your logic you should not see this document.

              I am no longer seeing #64 in the search results. Are you logging out of the manager when you do these tests?
                • 5811
                • 1,717 Posts
                After a long thought and some tests, I agree finally with you.

                I have donc some tests and when a document is restricted for the manager interface it is not be restricted for the website interface.
                The test
                (ISNULL(dg.document_group) OR (dg.document_group IN (1,2))
                is now replaced by
                ((dg.document_group IN (1,2)) OR (sc.privateweb=0))

                The version 1.8.2 has been fixed with this correction. You could run a search with "proud" to see the differences with the release 1.8.1

                Please find enclosed a fix for the version 1.8.1 (a new version of the file classes/search.class.inc.php). I have done some tests, but as I have done some important change in this file, do several search tests before to launch in production this new release. Let me know the results.
                The issue has been registered as AJAXSEARCH-27
                  • 31178
                  • 128 Posts
                  After a long thought and some tests, I agree finally with you.
                  Great!! smiley and thank you for staying with me on this. I appreciate your time, work and the quick provision of a patch!

                  I have done tests with the 1.8.1e update you provided and yes it now functions as expected when testing with combinations of manger groups and web groups, both logged in as a manager and/or a web user.

                  Thanks again, Richard