Details

    • Story Points:
      0.25
    • Fix Priority:
      3

      Description

      Reproduction steps:

      • Set up a vanilla DXP with fix pack de-40 and start it.
      • Create a new site.
      • In default site go to "Documents and Media" and click on the 3 dots on the upper right and select "Home Folder Permissions", then at the Site Member I unchecked all boxes then save it.
      • Export the "Documents and Media" home folder and enabled "Export permissions" and downloaded the LAR file.
      • Import the LAR file and enabled "Import permissions" to the created site.

      Actual Result: The imported LAR into the new site does not contain the permission changes.

      Expected Result: LAR should be successfully imported with the permission changes.

      Note:

      The issue is reproducable if you add any folder or content to the Home folder.
      By default the Content checkbox is checked in this case, but if you uncheck it and only check the Export Permissions checkbox,
      than the permissions will not be exported.

      So, i think the Content checkbox not should be checked for exporting permissions, only the Export Permissions checkbox must be checked.
      And this is not realted only to the Documents and Media, it is related to all export/import.

      Checking the request is sent to the server:
      the Form data DLAdminPortlet always true, no matter the Content checkbox is checked or not.

      Checking the backend at com.liferay.exportimport.internal.lar.PermissionExporter::exportPortletDataPermissions(PortletDataContext portletDataContext)

      • in case the Content checkbox is checked: the portletDataContext.getPermissions() map contains the permissions
      • in case the Content checkbox is NOT checked: the portletDataContext.getPermissions() is empty

      But only when exporting content in the DLPortletDataHandler::doExportData method is adding permissions to the portletDataContext.

      portletDataContext.addPortletPermissions(DLConstants.RESOURCE_NAME);

      I tested the case with the latest fix pack and is reproducible.

      I tested the case with portal 6.2 and it worked fine (not reproducible).

       7.0.x @ 9384e00cab8cd95e68459f9f25c39c948de041de

       master @ 0ce95cea33dde113c37105d8729a78b50b1e3b3d

        Attachments

          Activity

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                1 year, 17 weeks, 2 days ago

                Packages

                Version Package