Contexts

Cloud CMS uses a browser-side configuration service that evaluates "blocks" of configuration rules to determine the overall runtime configuration that drives every page render. Each block contains an evaluator and a snippet of configuration.

If the evaluator evaluates to true, the snippet of configuration is included. It is merged into the overall runtime set and then used to make rendering decisions.

Most of the Cloud CMS components that render on the screen, such as the left-hand navigation menu or list buttons that appear as users navigate the document library, are driven from this configuration. These components get their configuration from a context.

This section of the documentation describes the structure of these context configurations as they are most often what you will want to extend.

The following context keys are available for extension:

Schemas

While there are many context keys that you can extend, you will find that they all adhere to a common schema. You will typically want to override, remove or append one of the following kinds of things:

actions
navigation items

Actions

Each action supports a binding like this:

{
    "key": "{key}",                      (required)
    "title": "{title}",                  (required)
    "action": "{action}",
    "module": "{module}",
    "iconClass": "{iconClass}",    
    "order": {order},
    "allowPermission": [],
    "rejectPermission": [],
    "allowAuthority": [],
    "rejectAuthority": [],
    "allowTeam": [],
    "rejectTeam": []
}

Where the following are required:

key - a required field that provides a unique identifier for the action. This key is used to reference the action programmatically.
title - a display friendly label for the action

To invoke the action, you will need to provide one of the following:

action - an action type that references a registered Action implementation. This can either be your own Action implementation or one of the out-of-the-box actions that Cloud CMS provides.
module - a path to the AMD module that implements the action. If you use this approach, the action will be require'd in and then invoked.

The following is optional and is used to adjust how your action will appear:

iconClass - CSS classes to append to the icon holder when rendered. This is typically something like fa fa-plus.
order - The integer insertion order of your action. Lower numbers are sorted higher.

The following is optional and is used to adjust when your action will appear:

allowPermission - an array of permission IDs. If the user has any of these permissions, the action will appear.
rejectPermission - an array of permission IDs. If the user has any of these permissions, the action will not appear.
allowAuthority - an array of role keys. If the user has any of these roles, the action will appear.
rejectAuthority - an array of role keys. If the user has any of these roles, the action will not appear.
allowTeam - an array of team keys. If the user belongs to any of these teams, the action will appear.
rejectTeam - an array of team keys. If the user belongs to any of these teams, the action will not appear.

Invoking by Action ID

Here is an example that fires the out-of-the-box new_folder action.

{
    "key": "custom/new-folder",
    "title": "New Folder",
    "action": "new_folder"
}

Invoking by Module Path

Custom actions are defined in modules that are registered through the UI extension framework.
The implementation classes can be referenced like this:

{
    "key": "myaction",
    "title": "My Action",
    "module": "custom/actions/my-action"
}

Navigation Items

Each nav item supports a binding like this:

{
    "key": "{key}",                 (required)
    "title": "{title}",             (required)
    "uri": "{uri}",                 (required)
    "iconClass": "{iconClass}",
    "cssClass": "{cssClass}",
    "order": {order},
    "header": {header},
    "allowPermission: [],
    "rejectPermission": {],
    "allowAuthority: [],
    "rejectAuthority": {]   ,
    "allowTeam": [],
    "rejectTeam": [] 
}

Where the following are required:

key - a required field that provides a unique identifier for the navigation item. This key is used to reference the navigation item programmatically.
title - a display friendly label for the navigation item
uri - a URI that is dispatched to when the navigation item is clicked

The following is optional and is used to adjust how your navigation item will appear:

iconClass - CSS classes to append to the icon holder when rendered. This is typically something like fa fa-plus.
cssClass - CSS classes to append to the menu item when rendered.
order - The integer insertion order of your action. Lower numbers are sorted higher.
header - If this is set to true, the navigation item will be rendered as a header (and won't be clickable).

The following is optional and is used to adjust when your navigation item will appear:

allowPermission - an array of permission IDs. If the user has any of these permissions, the navigation item will appear.
rejectPermission - an array of permission IDs. If the user has any of these permissions, the navigation item will not appear.
allowAuthority - an array of role keys. If the user has any of these roles, the navigation item will appear.
rejectAuthority - an array of role keys. If the user has any of these roles, the navigation item will not appear.
allowTeam - an array of team keys. If the user belongs to any of these teams, the navigation item will appear.
rejectTeam - an array of team keys. If the user belongs to any of these teams, the navigation item will not appear.

Dashboard

The dashboard key defines a dashboard consisting of rows, columns and dashlets that are mounted into framing cells. Dashlets appear in several places within the Cloud CMS interface including the platform landing page, the project landing page and the warehouse landing page.

To populate the dashboard section, your configuration snippet should look like this:

{
    "dashboard": {
        "rows": []
    ]
}

Rows, Columns and Dashlets

Each dashboard defines rows, columns and dashlets. Here is an example with 2 rows, 2 columns each and a dashlet bound to the upper-left and lower-right cells.

{
    "dashboard": {
        "rows": [{
            "cols": [{
                "dashlets": [{
                    "title": "My Project Documents",
                    "type": "project-content",
                    "chrome": true
                }]
            }, {
                "dashlets": []
            }]
        }, {
            "cols": [{
                "dashlets": []
            }, {
                "dashlets": [{
                    "title": "My Project Tasks",
                    "type": "project-tasks",
                    "chrome": true                
                }]
            }]
        }]
    ]
}

The following properties may be specified per dashlet:

type identifies the kind of dashlet to bind into the cell
chrome specifies whether to render the framed border around the dashlet (with title bar)
title is the title to render for the dashlet (if chrome is true)

You may bind multiple dashlets per cell. The will be stacked for you.

Example - Override a Dashboard

You can override any of the out-of-the-box dashboards by using the replace property, like this:

{
    "replace": true,
    "dashboard": {
        "rows": [{
            "cols": [{
                "dashlets": [{
                    "title": "My Project Documents",
                    "type": "project-content",
                    "chrome": true
                }]
            }, {
                "dashlets": []
            }]
        }, {
            "cols": [{
                "dashlets": []
            }, {
                "dashlets": [{
                    "title": "My Project Tasks",
                    "type": "project-tasks",
                    "chrome": true                
                }]
            }]
        }]
    ]
}