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 -
          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 ]
          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 ]
          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 ]
          André Rømcke made changes -
          Link This issue testing discovered EZP-29400 [ EZP-29400 ]
          André Rømcke made changes -
          Status Documentation Review done [ 10011 ] Closed [ 6 ]
          Fix Version/s 2018.06 [ 14890 ]
          Resolution Fixed [ 1 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: