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

As an editor I want to be able to see the locations of a content in the "Location" location view tab

    Details

      Description

      Implementing the Location location view tab that lists the Location of a content. Also while waiting for
      Adding, removing, hiding, or changing the main location are outside of the scope of this issue and will be implemented in the related stories.

      For each location, the breadcrumb has to be loaded. We already have some code to do that in the location view view service. This code should be moved to a Location model so that we can reuse it there.

      see https://doc.ez.no/display/PR/Content+view+subtabs#Contentviewsubtabs-Locations

        Issue Links

          Activity

          Hide
          Roland Benedetti added a comment -

          [~yannick.roger@ez.no]
          Small note: I uploaded the wireframe here https://doc.ez.no/display/PR/Content+view+subtabs?focusedCommentId=27395714#comment-27395714
          For each location, we should have a button that can open the content at its location, in a new tab of the browser. It will be handy for editors.
          Buttons should be inactive when the location is hidden.

          Show
          Roland Benedetti added a comment - [~yannick.roger@ez.no] Small note: I uploaded the wireframe here https://doc.ez.no/display/PR/Content+view+subtabs?focusedCommentId=27395714#comment-27395714 For each location, we should have a button that can open the content at its location, in a new tab of the browser. It will be handy for editors. Buttons should be inactive when the location is hidden.
          Hide
          Damien Pobel (Inactive) added a comment -

          This should be split in 2 stories:

          • first display the location list of the content currently being viewed
          • implement the action on those locations.

          On the actions on the Location, having the "Remove selected" button so far away from the related checkboxes is a bit weird. Usually, the button in such cases is positioned below table (and maybe with a duplicate on the top of the table if we think the table will be huge but it's not that common to have tons of the Locations for a given content).

          Also, I guess that changing the radio button changes the main location with a REST call but do we ask for the confirmation before doing that ? In addition, given the structure of the application (it's an application) and the resources it needs to boostrap, I'm not sure it's a good idea to have links opening new browser tab. And last, there's no way to change the visibility of the Location it seems ?

          Show
          Damien Pobel (Inactive) added a comment - This should be split in 2 stories: first display the location list of the content currently being viewed implement the action on those locations. On the actions on the Location, having the "Remove selected" button so far away from the related checkboxes is a bit weird. Usually, the button in such cases is positioned below table (and maybe with a duplicate on the top of the table if we think the table will be huge but it's not that common to have tons of the Locations for a given content). Also, I guess that changing the radio button changes the main location with a REST call but do we ask for the confirmation before doing that ? In addition, given the structure of the application (it's an application) and the resources it needs to boostrap, I'm not sure it's a good idea to have links opening new browser tab. And last, there's no way to change the visibility of the Location it seems ?
          Hide
          Damien Pobel (Inactive) added a comment - - edited

          Dev note:
          Besides the behaviour question, the first thing to do is to implement the view of the Location list. Here again, it's an asynchronous view that will fire an event to get the list of locations of a given content. The event will be handled by a location view service plugin The content model should probably provide a method to get the location lists.

          Show
          Damien Pobel (Inactive) added a comment - - edited Dev note: Besides the behaviour question, the first thing to do is to implement the view of the Location list. Here again, it's an asynchronous view that will fire an event to get the list of locations of a given content. The event will be handled by a location view service plugin The content model should probably provide a method to get the location lists.
          Hide
          Roland Benedetti added a comment -

          "On the actions on the Location, having the "Remove selected" button so far away from the related checkboxes is a bit weird. Usually, the button in such cases is positioned below table (and maybe with a duplicate on the top of the table if we think the table will be huge but it's not that common to have tons of the Locations for a given content)."

          > Yes, true, there is no UI design on these. I am fine if we move the action bottom at the bottom.

          "Also, I guess that changing the radio button changes the main location with a REST call but do we ask for the confirmation before doing that ? "

          > Yes see updated

          "In addition, given the structure of the application (it's an application) and the resources it needs to boostrap, I'm not sure it's a good idea to have links opening new browser tab. "

          > updated, we remove this idea. But editors will anyway do a left click, open in new window... so we have a problem here. Let's keep it for later.

          And last, there's no way to change the visibility of the Location it seems ?

          > added back. I'll try to have U.I. design for icons there if we have time. Otherwise just go for standard text.

          Show
          Roland Benedetti added a comment - "On the actions on the Location, having the "Remove selected" button so far away from the related checkboxes is a bit weird. Usually, the button in such cases is positioned below table (and maybe with a duplicate on the top of the table if we think the table will be huge but it's not that common to have tons of the Locations for a given content)." > Yes, true, there is no UI design on these. I am fine if we move the action bottom at the bottom. "Also, I guess that changing the radio button changes the main location with a REST call but do we ask for the confirmation before doing that ? " > Yes see updated "In addition, given the structure of the application (it's an application) and the resources it needs to boostrap, I'm not sure it's a good idea to have links opening new browser tab. " > updated, we remove this idea. But editors will anyway do a left click, open in new window... so we have a problem here. Let's keep it for later. And last, there's no way to change the visibility of the Location it seems ? > added back. I'll try to have U.I. design for icons there if we have time. Otherwise just go for standard text.
          Hide
          Damien Pobel (Inactive) added a comment -

          divided the story in smaller stories.

          Show
          Damien Pobel (Inactive) added a comment - divided the story in smaller stories.
          Show
          Mateusz Hyndle (Inactive) added a comment - PR: https://github.com/ezsystems/PlatformUIBundle/pull/336
          Show
          Mateusz Hyndle (Inactive) added a comment - Merged in master: https://github.com/ezsystems/PlatformUIBundle/commit/3ca9f3c2d73b03506e7a5e2808ea995423d86e10
          Hide
          Rui Silva (Inactive) added a comment -

          Tested and approved by QA for master.

          Show
          Rui Silva (Inactive) added a comment - Tested and approved by QA for master.

            People

            • Assignee:
              Unassigned
              Reporter:
              Roland Benedetti
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 week, 6 hours, 30 minutes
                1w 6h 30m