Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-55121

Bad Data from AP Scoping Issue Persists in DB

    Details

      Description

      The issue: LPS-53643

      Unfortunately it turned out that the fix can't fix the existing wrong reference, it just prevents this issue from happening again. The wrong reference remains in the database.

      Reproduction steps:
      1) Create a site "site-a" and add a Structure in this site
      2) Create a new site "site-b", create a page in this site and place an asset publisher portlet on this page. Open this AP portlet configuration and just save.
      3) Export this site-b
      4) Try to import the exported lar to a new site "site-c"
      Import will get fail and will produce errors that Asset Publisher has some references to some ADT's which are not located.
      5) Install liferay-hotfix-5820-6210.zip ( It contains this fix: LPS-53643)
      6) Create a new export of site-b
      7) Try to import the new LAR file. The same issue occurs.

      Note: To see that the hotfix fixes this issue you can repeat the steps from 1-4 with new sites.

      The problem:
      Prior the hotfix the Asset Publisher saves the wrong reference (the unrelated site's structures' ID in porletpreferences table:
      <preference><name>classTypeIdsJournalArticleAssetRendererFactory</name><value>10815</value></preference>
      After the fix, it does not happen anymore, however the fix does not fix the existing wrong reference.

      The task: We should find a way to remove this wrong reference.

      Update: LPS-53643 prevents the issue from happening and corrects bad APs, however the process to do this is a manual one. Certain instances of LR may have dozens of APs scattered across multiple sites, so the objective of this LPS is so create a way for all of the affected APs to be fixed automatically.

      The reason this issue is not reproducible in master is due to the "Basic Document" global structure LR creates by default. This bug only occurs when we go from 1 or more structures within scope, to zero structures within scope. Basically, if we have zero structures and save the configuration, we do not update the ClassTypeId(class name here) value in the portetProperties, so we are accidentally saving the old value(s). Because Master has a global structure, we will always have at least one structure within scope, therefore dodging the bug. I was unable to delete the "Basic Document" global structure within LR, but I could do so by manipulating the DB directly. After deleting the structure, I was able to reproduce the bug.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              sherry.zhu Sherry Zhu (Inactive)
              Reporter:
              christopher.kian Christopher Kian
              Participants of an Issue:
              Recent user:
              Esther Sanz
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Days since last comment:
                6 years, 36 weeks, 2 days ago

                  Packages

                  Version Package
                  6.2.4 CE GA5
                  6.2.X EE
                  7.0.0 M5