Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-27101

Getting MetaData of an object linked in 2 Object Relations within the same content

    Details

      Description

      There is a bug in eZ Publish Legacy regarding metaData sent to Solr when 2 relationList are added to the same class and same content added in both relation.

      Steps to reproduce :

      1. Create a class "Test" with a name and 2 object Relations "relation1" and "relation2".
      2. Create 2 articles "article1" and "article2"
      3. Create a content of that class "Test".
      4. In "relation1", add "article1"
      5. In "relation2", add "article1" and "article2".
      6. When publishing your content, have a look on metaData "attribute_relationN_t" returned by function eZRelationListType::metaData.
      • For "relation1", you will get "article1" metadata
      • For "relation2", as "article1" has been already parsed within "relation1", $GLOBALS["ez_content_object_recursion_protect"] contains "article1.id" and when testing "if ( eZContentObject::recursionProtect( $subObjectID ) )", it returns false and so, attributes of "article1" are not returned for metaData of "relation2".

      I think this test of recursionProtect is only there to avoid adding twice metadata of the same content within the same relation.
      In that case, it avoids also to add metaData of an already linked content within another relationList.

      Added by the Support Team

      This wrong behaviour can also be observed when using Legacy Search Engine, not necessarily only when using Solr.
      After publishing the Content of the class "Test" from the "Steps to reproduce", execute the following query on your database (change the contentobject_id to the one of the published Content):

      SELECT DISTINCT contentclass_attribute_id FROM ezpublish.ezsearch_object_word_link WHERE word_id = (SELECT id FROM ezpublish.ezsearch_word WHERE word = "article1") AND contentobject_id=100;
      

      There should be two results of this query (because "article1" should be linked to two different Content Attributes), but due to this bug, there will be only one result.

        Issue Links

          Activity

          Flo HUCK created issue -
          Show
          Flo HUCK added a comment - https://github.com/ezsystems/ezpublish-legacy/pull/1288
          Hide
          Flo HUCK added a comment -

          my fix remove $GLOBALS["ez_content_object_recursion_protect"] after looping on all contents of a relationList.
          Like this, we still avoid adding twice metadata of the same relationList but allow getting metadata in another relationList for the same content.

          Show
          Flo HUCK added a comment - my fix remove $GLOBALS ["ez_content_object_recursion_protect"] after looping on all contents of a relationList. Like this, we still avoid adding twice metadata of the same relationList but allow getting metadata in another relationList for the same content.
          Alex Schuster made changes -
          Field Original Value New Value
          Workflow EZ* Development Workflow [ 103113 ] EZEE Development Workflow [ 107814 ]
          Jacek Foremski (Inactive) made changes -
          Description
          There is a bug in eZ Publish Legacy regarding metaData sent to Solr when 2 relationList are added to the same class and same content added in both relation.

          Steps to reproduce :
          Create a class "Test" with a name and 2 object Relations "relation1" and "relation2".
          Create 2 articles "article1" and "article2"
          Create a content of that class "Test".
          In "relation1", add "article1"
          In "relation2", add "article1" and "article2".
          When publishing your content, have a look on metaData "attribute_relationN_t" returned by function eZRelationListType::metaData.
           - For "relation1", you will get "article1" metadata
           - For "relation2", as "article1" has been already parsed within "relation1", $GLOBALS["ez_content_object_recursion_protect"] contains "article1.id" and when testing "if ( eZContentObject::recursionProtect( $subObjectID ) )", it returns false and so, attributes of "article1" are not returned for metaData of "relation2".

          I think this test of recursionProtect is only there to avoid adding twice metadata of the same content within the same relation.
          In that case, it avoids also to add metaData of an already linked content within another relationList.
          There is a bug in eZ Publish Legacy regarding metaData sent to Solr when 2 relationList are added to the same class and same content added in both relation.

          Steps to reproduce :
          Create a class "Test" with a name and 2 object Relations "relation1" and "relation2".
          Create 2 articles "article1" and "article2"
          Create a content of that class "Test".
          In "relation1", add "article1"
          In "relation2", add "article1" and "article2".
          When publishing your content, have a look on metaData "attribute_relationN_t" returned by function eZRelationListType::metaData.
           - For "relation1", you will get "article1" metadata
           - For "relation2", as "article1" has been already parsed within "relation1", $GLOBALS["ez_content_object_recursion_protect"] contains "article1.id" and when testing "if ( eZContentObject::recursionProtect( $subObjectID ) )", it returns false and so, attributes of "article1" are not returned for metaData of "relation2".

          I think this test of recursionProtect is only there to avoid adding twice metadata of the same content within the same relation.
          In that case, it avoids also to add metaData of an already linked content within another relationList.

          *Added by the Support Team*

          This wrong behaviour can also be observed when using Legacy Search Engine, not necessarily only when using Solr.
          After publishing the Content of the class "Test" from the "Steps to reproduce", execute the following query on your database (change the {{contentobject_id}} to the one of the published Content):
          {code}
          SELECT DISTINCT contentclass_attribute_id FROM ezpublish.ezsearch_object_word_link WHERE word_id = (SELECT id FROM ezpublish.ezsearch_word WHERE word = "article1") AND contentobject_id=100;
          {code}
          There should be two results of this query (because "article1" should be linked to two different Content Attributes), but due to this bug, there will be only one result.
          Jacek Foremski (Inactive) made changes -
          Affects Version/s 5.4.11 [ 14717 ]
          Jacek Foremski (Inactive) made changes -
          Fix Version/s Customer request [ 11018 ]
          Jacek Foremski (Inactive) made changes -
          Status Open [ 1 ] Confirmed [ 10037 ]
          Jacek Foremski (Inactive) made changes -
          Status Confirmed [ 10037 ] InputQ [ 10001 ]
          Jacek Foremski (Inactive) made changes -
          Link This issue relates to CS-6105 [ CS-6105 ]
          Jacek Foremski (Inactive) made changes -
          Description There is a bug in eZ Publish Legacy regarding metaData sent to Solr when 2 relationList are added to the same class and same content added in both relation.

          Steps to reproduce :
          Create a class "Test" with a name and 2 object Relations "relation1" and "relation2".
          Create 2 articles "article1" and "article2"
          Create a content of that class "Test".
          In "relation1", add "article1"
          In "relation2", add "article1" and "article2".
          When publishing your content, have a look on metaData "attribute_relationN_t" returned by function eZRelationListType::metaData.
           - For "relation1", you will get "article1" metadata
           - For "relation2", as "article1" has been already parsed within "relation1", $GLOBALS["ez_content_object_recursion_protect"] contains "article1.id" and when testing "if ( eZContentObject::recursionProtect( $subObjectID ) )", it returns false and so, attributes of "article1" are not returned for metaData of "relation2".

          I think this test of recursionProtect is only there to avoid adding twice metadata of the same content within the same relation.
          In that case, it avoids also to add metaData of an already linked content within another relationList.

          *Added by the Support Team*

          This wrong behaviour can also be observed when using Legacy Search Engine, not necessarily only when using Solr.
          After publishing the Content of the class "Test" from the "Steps to reproduce", execute the following query on your database (change the {{contentobject_id}} to the one of the published Content):
          {code}
          SELECT DISTINCT contentclass_attribute_id FROM ezpublish.ezsearch_object_word_link WHERE word_id = (SELECT id FROM ezpublish.ezsearch_word WHERE word = "article1") AND contentobject_id=100;
          {code}
          There should be two results of this query (because "article1" should be linked to two different Content Attributes), but due to this bug, there will be only one result.
          There is a bug in eZ Publish Legacy regarding metaData sent to Solr when 2 relationList are added to the same class and same content added in both relation.

          Steps to reproduce :
          # Create a class "Test" with a name and 2 object Relations "relation1" and "relation2".
          # Create 2 articles "article1" and "article2"
          # Create a content of that class "Test".
          # In "relation1", add "article1"
          # In "relation2", add "article1" and "article2".
          # When publishing your content, have a look on metaData "attribute_relationN_t" returned by function eZRelationListType::metaData.
           * For "relation1", you will get "article1" metadata
           * For "relation2", as "article1" has been already parsed within "relation1", $GLOBALS\["ez_content_object_recursion_protect"] contains "article1.id" and when testing "if ( eZContentObject::recursionProtect( $subObjectID ) )", it returns false and so, attributes of "article1" are not returned for metaData of "relation2".

          I think this test of recursionProtect is only there to avoid adding twice metadata of the same content within the same relation.
          In that case, it avoids also to add metaData of an already linked content within another relationList.

          *Added by the Support Team*

          This wrong behaviour can also be observed when using Legacy Search Engine, not necessarily only when using Solr.
          After publishing the Content of the class "Test" from the "Steps to reproduce", execute the following query on your database (change the {{contentobject_id}} to the one of the published Content):
          {code}
          SELECT DISTINCT contentclass_attribute_id FROM ezpublish.ezsearch_object_word_link WHERE word_id = (SELECT id FROM ezpublish.ezsearch_word WHERE word = "article1") AND contentobject_id=100;
          {code}
          There should be two results of this query (because "article1" should be linked to two different Content Attributes), but due to this bug, there will be only one result.
          Jacek Foremski (Inactive) made changes -
          Component/s Search [ 10825 ]
          Jacek Foremski (Inactive) made changes -
          Assignee Jacek Foremski [ jacek.foremski@ez.no ]
          Jacek Foremski (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Hide
          Jacek Foremski (Inactive) added a comment - - edited

          The PR above can cause an infinite recursion (as described in https://github.com/ezsystems/ezpublish-legacy/pull/1288#issuecomment-292988830).

          New PR: https://github.com/ezsystems/ezpublish-legacy/pull/1371 - After the internal discussion, we decided to close this PR. I'll make another one which will remove the recursive logic in the least BC-breaky way as possible.

          Show
          Jacek Foremski (Inactive) added a comment - - edited The PR above can cause an infinite recursion (as described in https://github.com/ezsystems/ezpublish-legacy/pull/1288#issuecomment-292988830 ). New PR: https://github.com/ezsystems/ezpublish-legacy/pull/1371 - After the internal discussion, we decided to close this PR. I'll make another one which will remove the recursive logic in the least BC-breaky way as possible.
          Jacek Foremski (Inactive) made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Jacek Foremski (Inactive) made changes -
          Status Development Review [ 10006 ] InputQ [ 10001 ]
          Assignee Jacek Foremski [ jacek.foremski@ez.no ]
          Jacek Foremski (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Jacek Foremski [ jacek.foremski@ez.no ]
          Hide
          Jacek Foremski (Inactive) added a comment -

          Another PR, which removes the recursive behavior altogether: https://github.com/ezsystems/ezpublish-legacy/pull/1372.

          Show
          Jacek Foremski (Inactive) added a comment - Another PR, which removes the recursive behavior altogether: https://github.com/ezsystems/ezpublish-legacy/pull/1372 .
          Jacek Foremski (Inactive) made changes -
          Status Development [ 3 ] Development Review [ 10006 ]
          Jacek Foremski (Inactive) made changes -
          Comment [ A comment with security level 'QA' was removed. ]
          Jacek Foremski (Inactive) made changes -
          Status Development Review [ 10006 ] Documentation Review done [ 10011 ]
          Assignee Jacek Foremski [ jacek.foremski@ez.no ]
          Show
          Jacek Foremski (Inactive) added a comment - PR merged: https://github.com/ezsystems/ezpublish-legacy/commit/3539b9c05d5b69f04a4d340c67056af0044f603a
          André Rømcke made changes -
          Link This issue testing discovered EZP-29400 [ EZP-29400 ]
          Hide
          André Rømcke added a comment -

          Note: additional fix for this done in EZP-29400.

          Show
          André Rømcke added a comment - Note: additional fix for this done in EZP-29400 .
          André Rømcke made changes -
          Status Documentation Review done [ 10011 ] Closed [ 6 ]
          Fix Version/s 2018.06 [ 14890 ]
          Resolution Fixed [ 1 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Confirmed Confirmed
          371d 23h 14m 1 jacek.foremski@ez.no 20/Mar/18 2:44 PM
          Confirmed Confirmed InputQ InputQ
          14s 1 jacek.foremski@ez.no 20/Mar/18 2:44 PM
          Development Review Development Review InputQ InputQ
          2h 34m 1 jacek.foremski@ez.no 27/Jun/18 12:41 PM
          InputQ InputQ Development Development
          97d 19h 22m 2 jacek.foremski@ez.no 27/Jun/18 12:41 PM
          Development Development Development Review Development Review
          2d 1h 34m 2 jacek.foremski@ez.no 28/Jun/18 3:15 PM
          Development Review Development Review Documentation Review done Documentation Review done
          19h 17m 1 jacek.foremski@ez.no 29/Jun/18 10:33 AM
          Documentation Review done Documentation Review done Closed Closed
          172d 6h 6m 1 André Rømcke 18/Dec/18 3:40 PM

            People

            • Assignee:
              Unassigned
              Reporter:
              Flo HUCK
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: