Search Results

Rules

Rules Content Rules provide a way for you to wire in business logic behind the content graph. Once they're set up, rules run automatically as content is created, updated and deleted within your branch. Rules are content nodes with a JSON payload the describes the Conditions and Actions to be triggered. As with all behaviors, Rule nodes must implement the f:behavior feature. They must be bound to a node upon which to act (either a definition node or a content instance) using a a:has_behavio

Score: 13.990372

Overview

Overview Cloud CMS lets you wire in behaviors behind your content models so that rules automatically execute when your content is touched. Content editors work with simple forms to create content that conforms to your defined content models. When that content is created, updated or deleted, it automatically triggers policies (or events) which you use to bind in custom behaviors.

Score: 13.214895

Overview

Overview Policies can be used to run custom code or fire off actions when an event, such as creating a content item or associating a content item into the content graph, occurs. Cloud CMS provides a wide array of policies that you can hook your custom logic into. By default, Cloud CMS provides sensible and useful content policy handlers to manage the lifecycle of you content. You can wire in new policy handlers. Policy handlers include scripts and rules. The following types of policies are

Score: 12.9610405

Scripts

Scripts Scripts are content nodes with a default attachment of type application/javascript. As with all behaviors, script nodes must implement the f:behavior feature. They must be bound to a node upon which to act (either a definition node or a content instance) using a a:has_behavior association. Script Interfaces If you elect to write scripts to implement custom behaviors, the following signatures can be used inside of your JavaScript: Association Policies function beforeAssociate

Score: 7.6862617

Node Policies

Node Policies Node policies provide places where you can hook in behaviors that trigger when nodes are created, updated or deleted within the graph. Nodes may either be entities or associations. This provides an ideal way to plug in your custom behaviors for any definition or content instance within your content graph. The following policies are available: Policy QName Description p:beforeCreateNode Raised before a piece of content is created p:afterCreateNode Raised after a piece of con

Score: 7.3917603

Association Policies

Association Policies Association policies provide places where you can hook in behaviors that trigger when associations are created or removed between two nodes in the Cloud CMS content graph. When two nodes are connected together via an association or an association is broken, these policies trigger and may fire into your custom handlers. The following policies are available: Policy QName Description p:beforeAssociate Raised before an association is created between two nodes p:afterAssoc

Score: 7.2020936

Property Policies

Property Policies Property policies provide places where you can hook in behaviors that trigger when a property is created, updated or deleted. They allow you to get very granular about when you custom code is invoked - such as only when a specific property in your content is affected. The following property policies are available: Policy QName Description p:beforeCreateProperty Raised before a property on a node is created p:afterCreateProperty Raised after a property on a node is create

Score: 6.6603084

How does security work in Cloud CMS?

Cloud CMS provides two ways to describe access rights to things:

  • Object-level / role-based authorities
  • Team / role-based authorities

With object-level / role-based authorities, you assign a principal (either a user or a group) a role against something.  For example, you might give Joe the CONSUMER role against a content node.  When Joe then interacts with the content node in the future, he will do so with the CONSUMER role which will allow him to "read" the

Score: 6.6462574

Security

Security Cloud CMS provides two ways to describe access rights to things: Object-level / role-based authorities Team / role-based authorities With object-level / role-based authorities, you assign a principal (either a user or a group) a role against something. For example, you might give Joe the CONSUMER role against a content node. When Joe then interacts with the content node in the future, he will do so with the CONSUMER role which will allow him to "read" the node. With team / role

Score: 6.561071

Data List Policies

Data List Policies Data List policies provide places where you can hook in behaviors that trigger when items within a data list are operated upon. When items are added to a data list, removed from a data list or updated, these policies trigger and may fire into your custom handlers. The following policies are available: Policy QName Description p:beforeAddListItem Raised before an item is added to a list p:afterAddListItem Raised after an item is added to a list p:beforeUpdateListItem Ra

Score: 6.3203516