"Restricted" page editor

Version 12

    Status

    An implementation of this specification is ready. (Post GateIn 3.6)

    Description

    A customer is willing to give the ability to many different users to edit pages. Those users would require a simplified page editor and be constrained to simple actions. In particular, users should not be able to compose complex pages and risk to break the layouts.

    The layouts should be restricted to what is available from the "Containers" tab of the editor.


    In particular the 2 following scenarios should not be possible:

    • Scenario 1: User should not be able to put an application above/below the 2 column layout (As this break the pre-defined layouts, suddenly the user is able to have a single column representation while this may not have been provided):

    verboten1.png

    • Scenario 2: User should not be able to put a layout within a layout (only above or below existing ones)

    verboten2.png

    Proposed solution


    Add two new attributes to Pages and Containers:

    • move-apps-permissions
    • move-containers-permissions

    They both would contain the same kind of roles/groups list like the existing access-permissions.

    To play well with portals migrated from older GateIn versions and so that the default GateIn behavior would stay the same like it was in previous versions, both move-*-permissions would default to Everybody if they are not set explicitly.

    To achieve the behavior requested by the customer, one can create a portal extension (like this one) and override the GateIn defaults therein. E.g. for the "Two Columns" layout the customer would have to customize the its two-columns/page.xml file like this:

    <page
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.gatein.org/xml/ns/gatein_objects_1_6 http://www.gatein.org/xml/ns/gatein_objects_1_6"
        xmlns="http://www.gatein.org/xml/ns/gatein_objects_1_6">
      <name></name>
      <add-application-permissions>Nobody</add-application-permissions>
      <container template="system:/groovy/portal/webui/container/UITableColumnContainer.gtmpl">
        <access-permissions>Everyone</access-permissions>
        <add-application-permissions>Nobody</add-application-permissions>
        <add-container-permissions>Nobody</add-container-permissions>
        <container template="system:/groovy/portal/webui/container/UIContainer.gtmpl">
          <access-permissions>Everyone</access-permissions>
          <add-container-permissions>Nobody</add-container-permissions>
        </container>
        <container template="system:/groovy/portal/webui/container/UIContainer.gtmpl">
          <access-permissions>Everyone</access-permissions>
          <add-container-permissions>Nobody</add-container-permissions>
        </container>
      </container>
    </page>
    
    
    
    
    
    
    
    

    Note that <move-*-permissions>Nobody</move-*-permissions> is a shorthand for <move-*-permissions /> - i.e. for an empty list of permissions. In this way, all users (excluding root) are forbidden to place the given kind of component (container or portlet) on the given position in the hierarchy.

     

    Permission Setting UI


    This specification adds the ability to set Move-*-Permission of permissions at different location of the UI. They all user the same UI for which we define the specification below


    IDDescription
    PERMISSIONS_UI_01a checkbox labeled : Everyone. The default value is checked. It means everybody has the corresponding permission
    PERMISSIONS_UI_02A table with 3 columns Group ID, Membership, Action
    PERMISSIONS_UI_03Action column contains a trash icon with tooltip : Delete. A click on Delete removes the entry
    PERMISSIONS_UI_04An Add Permission primary button allows to select a group and membership and append a corresponding entry in the permissions table
    PERMISSIONS_UI_05Users matching the group/memberships defined in the table are granted the permission
    PERMISSIONS_UI_06If there is no entry in the table, nobody is granted the permission except the super user


    Site Permissions

    sitePermission.png

    IDDescription
    SITE_01  Edit > Site > Layout > Site's Config > Permission Settings,   is renamed to Permissions
    SITE_02Inside Permissions, Access Permission Settings and Edit Permissions Settings are renamed respectively to Access and Edit.
    SITE_03Inside Permissions, 2 new tabs are added  Move Apps and Move Containers
    SITE_04users can view the Move Apps and Move Containers if and only if they have the membership defined in UserACL  by : portal.administrator.mstype

     

    Page Permissions

    pagePermission.png

    IDDescription
    PAGE_01In Edit > Page > Edit Layout > View Page PropertiesPermission Settings is renamed to Permissions
    PAGE_02Inside Permissions, Access Permission Settings and Edit Permissions Settings are renamed respectively to Access and Edit.
    PAGE_03Inside Permissions, 2 new tabs are added  Move Apps and Move Containers
    PAGE_04for group pages, only users that have the membership defined by UserACL navigation.creator.membership.type in the group,  can view the Move Apps and Move Containers  buttons.
    PAGE_05for portal pages, only users that have the membership defined by UserACL portal.administrator.mstype can view the Move Apps and Move Containers  buttons.


    Container Permissions

    containerPermission.png

    IDDescription
    CONTAINER_01  In the popup displayed by Edit on a container from Edit > Site > Layout or Edit > Page > Edit Layout , Access Permission tab is renamed to Permissions
    CONTAINER_02Inside PermissionsAccess Permissions is renamed to Access
    CONTAINER_03Inside Permissions, 2 buttons are added, Move Apps, Move Containers.
    CONTAINER_04in Edit > Site > Layout > Site's Config, only users that have the membership defined by UserACL portal.administrator.mstype can access the Move Containers and Move Apps buttons.