Details

      Description

      Steps to reproduce
      • Create and publish one image/media/file with respective image/media/file
      • Send the created object to trash
      • Go to trash and restore the object
      • Click on content tree and select the restored object
      • Edit the image/media/file again

      Here we have a notification error

       Could not load the location with id '/api/ezp/v2/content/locations/1/2/59' 
      

        Issue Links

          Activity

          Hide
          Miguel das Neves Jacinto (Inactive) added a comment -

          +1 confirmed

          Show
          Miguel das Neves Jacinto (Inactive) added a comment - +1 confirmed
          Hide
          André Rømcke added a comment -

          Is this UI issue? As in are you able to edit it if you reload UI?

          Show
          André Rømcke added a comment - Is this UI issue? As in are you able to edit it if you reload UI?
          Hide
          Paulo Nunes (Inactive) added a comment - - edited

          If I reload UI, then it works.

          Further tests shows that the issue also happens with other objects besides the Images/files/media. Tried with a Folder and the same problem happens. Due that, i''l change the issue title.

          Show
          Paulo Nunes (Inactive) added a comment - - edited If I reload UI, then it works. Further tests shows that the issue also happens with other objects besides the Images/files/media. Tried with a Folder and the same problem happens. Due that, i''l change the issue title.
          Hide
          Damien Pobel (Inactive) added a comment -

          I'm not able to reproduce the issue but I'm unsure of what you are doing between the last 2 steps. Are you using the back button or are you browsing to the new Location of the restored Content item ? If it's the first option, it's normal it does not work as restoring the object basically mean creating a new Location for it so the previous URL does not work.

          Show
          Damien Pobel (Inactive) added a comment - I'm not able to reproduce the issue but I'm unsure of what you are doing between the last 2 steps. Are you using the back button or are you browsing to the new Location of the restored Content item ? If it's the first option, it's normal it does not work as restoring the object basically mean creating a new Location for it so the previous URL does not work.
          Hide
          Paulo Nunes (Inactive) added a comment -

          [~damien.pobel@ez.no] try in "prod" mode. I just tried again and in "prod" it happens, but in "dev" don't.
          After restoring the object, I select it through content tree and then I edit it. I added this extra step in the "steps to reproduce"

          Show
          Paulo Nunes (Inactive) added a comment - [~damien.pobel@ez.no] try in "prod" mode. I just tried again and in "prod" it happens, but in "dev" don't. After restoring the object, I select it through content tree and then I edit it. I added this extra step in the "steps to reproduce"
          Hide
          Damien Pobel (Inactive) added a comment -

          I was using the "prod" environment but I was browsing with the path + subitem, and indeed by using the tree I can reproduce the issue

          Show
          Damien Pobel (Inactive) added a comment - I was using the "prod" environment but I was browsing with the path + subitem, and indeed by using the tree I can reproduce the issue
          Hide
          Damien Pobel (Inactive) added a comment -

          Again, it's an HTTP cache issue (which expires after 60s and that's why the time you take to get back to the restored Content matters). So basically to display a Content item we load /api/ezp/v2/content/objects/<ContentId>?languages=eng-GB which is cached for 60 seconds by default but this resource is not purged from the reverse proxy when sending the Content to Trash nor when restoring. As a result, the resource still references the old Location not the new one when trying to edit it.

          Show
          Damien Pobel (Inactive) added a comment - Again, it's an HTTP cache issue (which expires after 60s and that's why the time you take to get back to the restored Content matters). So basically to display a Content item we load /api/ezp/v2/content/objects/<ContentId>?languages=eng-GB which is cached for 60 seconds by default but this resource is not purged from the reverse proxy when sending the Content to Trash nor when restoring. As a result, the resource still references the old Location not the new one when trying to edit it.
          Hide
          André Rømcke added a comment -

          Should have been fixed by EZP-25003.

          Show
          André Rømcke added a comment - Should have been fixed by EZP-25003 .
          Hide
          Paulo Nunes (Inactive) added a comment -

          Validated by QA
          tested on master for images, files and media

          Show
          Paulo Nunes (Inactive) added a comment - Validated by QA tested on master for images, files and media

            People

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

              Dates

              • Created:
                Updated:
                Resolved: