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

New draft based on a selected version doesn't respect ezkeywords value

    Details

    • Type: Improvement Improvement
    • Status: Development Review
    • Priority: High High
    • Resolution: Unresolved
    • Affects Version/s: 5.4.9, 1.7.2, 1.8.1, 1.9.0
    • Fix Version/s: QA tracked issues
    • Labels:
    • Environment:

      Operating System: Debian 8
      PHP Version: 5.6.14-0+deb8u1
      Database and version: Mysql 5.5.46-0+deb8u1
      Browser (and version): Firefox 51
      Env: Prod

      Description

      Steps to Reproduce

      -Add ezkeywords attribute to Article content type
      -Create one article with name "Article1" and ezkeyword fields "111". publish. This will create version1
      -Edit the created article and update name to "Article2" and ezkeyword field to "222". Publish. This will create version2
      -Go to "versions" tab of the article, and create a new draft based on verison1 (the one that has "111" as ezkeyword)
      -When we edit this new draft, we see that the article name is respected accordingly to the chosen version (Article1), but the ezkeywords is not. We have "222", that is related to version2 and not the chosen version (should be "111)

        Issue Links

          Activity

          Hide
          Damien Pobel (Inactive) added a comment - - edited

          We had exactly the same problem in Legacy. I think this is happening because the Keyword field value are not "versioned", this is a "known" issue reported in EZP-13580

          Show
          Damien Pobel (Inactive) added a comment - - edited We had exactly the same problem in Legacy. I think this is happening because the Keyword field value are not "versioned", this is a "known" issue reported in EZP-13580
          Hide
          Damien Pobel (Inactive) added a comment -

          so I added "Fieldtype" to the "Component/s" and it should be fixed in the repository (ping André Rømcke)

          Show
          Damien Pobel (Inactive) added a comment - so I added "Fieldtype" to the "Component/s" and it should be fixed in the repository (ping André Rømcke )
          Hide
          André Rømcke added a comment -

          Talked about this with Andrzej Longosz, so he can maybe add some insight on limitations / possibilities on what we can do in 1.x (as opposed to in 2.x).

          Show
          André Rømcke added a comment - Talked about this with Andrzej Longosz , so he can maybe add some insight on limitations / possibilities on what we can do in 1.x (as opposed to in 2.x).
          Hide
          Andrzej Longosz added a comment -

          Possible solutions:

          1. It seems to me (based on my experience with EZP-27015) that we really can't avoid "versioning" keywords. If we don't store versionNo, we can't reliably edit this field for any version that is not currently published.

          The best place for this in the database would be ezkeyword_attribute_link table with new version column, proper index and upgrade script.

          I'm aware that due to semantic versioning of our product, changing DB schema might be considered not the best choice, however we've done it before.
          The only thing is that it would be new feature added in new version of kernel, without a backport fix.

          2. The other solution we've discussed is to restore keywords for editing from DB column ezcontentobject_attribute.sort_key_string. However this column is varchar(255), so if someone creates longer list of keywords, this field value would break. Based on my experience long list of keywords is a common thing

          3. Taking a closer look at the ezcontentobject_attribute table, we also might store full keyword list in data_text column. This solution is not good because it leads to DB "denormalization", but allows to make a backport fix.

          Personally I prefer 1st solution.
          // ping André Rømcke

          // cc Sławomir Uchto, [~damien.pobel@ez.no]

          Show
          Andrzej Longosz added a comment - Possible solutions: 1. It seems to me (based on my experience with EZP-27015 ) that we really can't avoid "versioning" keywords. If we don't store versionNo, we can't reliably edit this field for any version that is not currently published. The best place for this in the database would be ezkeyword_attribute_link table with new version column, proper index and upgrade script. I'm aware that due to semantic versioning of our product, changing DB schema might be considered not the best choice, however we've done it before . The only thing is that it would be new feature added in new version of kernel, without a backport fix. 2. The other solution we've discussed is to restore keywords for editing from DB column ezcontentobject_attribute.sort_key_string . However this column is varchar(255) , so if someone creates longer list of keywords, this field value would break. Based on my experience long list of keywords is a common thing 3. Taking a closer look at the ezcontentobject_attribute table, we also might store full keyword list in data_text column. This solution is not good because it leads to DB "denormalization", but allows to make a backport fix. Personally I prefer 1st solution. // ping André Rømcke // cc Sławomir Uchto , [~damien.pobel@ez.no]
          Hide
          André Rømcke added a comment - - edited

          1. is clearly cleanest choice on first look, however unlike the example given about db changes we have done before this will most likely lead to db break for legacy as selects needs to take version into account to be able to get the unique keyword.

          If so, then 3rd option is probably the best one for version 1.x, making it somewhat work like relation and relation list (even though link table does have from version), but it will have to be able to understand empty data as well when data is coming from legacy.

          However this has issues with having to keep data in sync, so personally prefer option 1 for 2.x only, as this issue has been around for a long time and there hasn't been much complaints about it at all.

          Show
          André Rømcke added a comment - - edited 1. is clearly cleanest choice on first look, however unlike the example given about db changes we have done before this will most likely lead to db break for legacy as selects needs to take version into account to be able to get the unique keyword. If so, then 3rd option is probably the best one for version 1.x, making it somewhat work like relation and relation list (even though link table does have from version) , but it will have to be able to understand empty data as well when data is coming from legacy. However this has issues with having to keep data in sync, so personally prefer option 1 for 2.x only, as this issue has been around for a long time and there hasn't been much complaints about it at all.
          Show
          Andrzej Longosz added a comment - - edited PR: https://github.com/ezsystems/ezpublish-kernel/pull/1947

            People

            • Assignee:
              Andrzej Longosz
              Reporter:
              Paulo Nunes (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 day, 4 hours
                1d 4h