Uploaded image for project: 'Hippo CMS'
  1. Hippo CMS
  2. CMS-13373

Frontend : Support Author being able to modify the layout of Experience Pages in CM if (s)he has role Author on the Experience Page

    XMLWordPrintable

Details

    • New Feature
    • Status: Closed
    • Normal
    • Resolution: Fixed
    • 14.3.0
    • 14.3.0
    • None

    Description

      See RD-5403

      When an author browses a website in the CM and then visits a Experience Page (s)he has role Author on, the Experience Page layout (HST Components) should become editable

      Logical Implications

      When someone browses to a channel in the Channel Manager, we do not know on beforehand whether the specific user can potentially modify some Experience Pages : we do not know on which pages (s)he might have the role hippo:author. This means that anyone who can navigate a channel in the CM potentially can modify some pages in the CM (the layout). Hence, the current global check when opening the CM whether the user is a webmaster or not doesn't hold any more: A user can be

      • Webmaster and/or
      • Author on some XPages

      So when looking at a (x)page in the CM, it might be that the CMS user has write access to only the XPage container(items) or only the HST Config container(items) OR (s)he has write access to BOTH the XPage container(items) AND the HST Config container(items).

      Note that even if the user has write access to the XPage container(items) and to HST Config container(items), (s)he is still NOT allowed to drag drop items from XPage containers to HST Config containers and vice versa: this is because they have a different life cycle

      Technical Approach

      First of all, for now, we mark that every user has write privilege during the UI call to #composerModeGet : We set

      canWrite = true
      

      However, the Channel mgr UI code should not even look at this property any more. Instead it should look PER component whether the user is allowed to modify it! For this, we include to the html comment (or in PMA to the meta data) the following attributes for EVERY HST container, and container item :

      HST-Experience-Page-Component = true | false
      HST-Component-Editable = true | false
      

      Some users will only have editable for the container(item)s of an XPage, some only for HST Config container(item)s and some for both (eg a person in role webmaster on the hst config and in role hippo:author for the XPage document)

      Technical Implementation Details

      During the HST page rendering in the Channel Manager, we need per HST Component check whether the user is in the right role to be allowed to do so. For XPage components the required role is 'hippo:author' and for HST Config components the required role is 'hippo:channel-webmaster'. To be able to do so, we need to be able to access the JCR Session of the logged in CMS user. At this moment, during HST aggregation valve rendering, we do not have this user JCR Session. The user JCR Session is only created to be able to create a JCR Session which combines the preview HST Session with the CMS user Session (JCR Security delegation we call that). After that, the user JCR Session is logged out again. This needs to be done differently, we need to be able to access it during the aggregation valve (page generation) to check the privileges. For this, we need to hook into the CmsSecurityValve

      Once we have the CMS User JCR Session available, we can in CmsComponentComponentWindowAttributeContributor simply check the above mentioned roles against the HST Component

      Attachments

        1. Container switch button.png
          73 kB
          Carolien de Kort
        2. flask-outline.svg
          0.7 kB
          Carolien de Kort
        3. lock-24px.svg
          0.4 kB
          Carolien de Kort

        Issue Links

          Activity

            People

              ntrajkovski Nikola Trajkovski
              aschrijvers Ard Schrijvers
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: