The selected file /tmp/fileASfvlw could not be uploaded, because the destination sites/default/files/css/css_a91cd284035e73ba34d112bfed2f5a16.css is not properly configured.
  The selected file /tmp/filePR1RQi could not be uploaded, because the destination sites/default/files/css/css_de1aa27776f1462d2b0d83a80ce4b92d.css is not properly configured.

The Action Manager is the single interfacing for creating and maintaining Actions.

The Action Manager is accessed via the flyout menu for any interface-based Building Block by selecting the “Actions” menu option.

The Action Manager always launches in a popup window.

The primary interface elements within the Action Manager consist of:

1. Tabs that separate the available user triggers.
2. A procedure that includes all Blocks upon which Actions may be performed, as well as any Actions that have been created for those Blocks
3. A flyout menu for each Block in a procedure that allows the builder to create or edit Actions for that Block
4. An expand or edit feature that activates when the text description for any Action is clicked on
5. Limited ability to drag and drop Actions

There are two types of triggers accessible via the Action Manager:

1. User Triggers (three subtypes)
2. Scheduled Events
3. Action Sets

User triggers fire due to user interaction with your application. These triggers fire procedures that may contain Actions. Some examples include a user saving a page, clicking on a link, or tabbing off of a field.

This events happen within the interface while a user is navigating. This trigger encompasses those events commonly referred to as “javascript events”, such as “on mouseover”, “on focus”, etc.

Placing an Action in the procedure fired by one of these events will result in that Action being performed when the corresponding event takes place.

These triggers fire a procedure that occurs after a “Save” button is pressed on a Layout (including a page Layout) but before the actual saving of the Blocks in that Layout begins.

Start by choosing an event in the procedure to validate, and click on that event's Block, just like you would to add an Action to any other event. Initally, you'll only be able to add an evaluation Control Action. The evaluation could pass or fail, and an Action of type “Display an Error Message” should be used to generate a validation error.

If your evaluation passes, and if the “If This Evaluation Passes” branch has no Actions of type “Display an Error” present, then this event will validate. If an evaluation fails, then the system will check the “else” branch for any actions of type “Display an Error”. If it finds none, then the event will “validate”. At any point, if the evaulation finds a “Display an Error” Action in the approriate branch, it will follow that Action's instructions and display an error. There is only one possible Action Type here, “Display an Error”.

Inside the Action - Display An Error, use the Expression Builder Tool to create the error message you wish to display to your users.

Evaluations (validations) may be nested.

All events in a procedure and their associated Actions are processed in order, from top to bottom, modified only by evaluations, looping expressions, or switches.

These triggers fire a procedure after a “Save” button is pressed on a Layout (including a page Layout) and after ALL “Pre-Save Validation” events have succesfully resolved without resulting in an error message (see above) displayed to the user.

Start by choosing an event in the procedure for which you'd like to create an Action, and click on that event's Block. From the resulting menu, choose which Execution or Control Action you'd like to create.

You may explore the deep nesting options of Actions within procedures.

All events in a procedure and their associated Actions are processed in order, from top to bottom, modified only by evaluations, looping Expressions, or switches.

Scheduled events trigger procedures that take place according to a pre-determined schedule.

Action Sets are sets of Actions that can be referred to from either a Scheduled Event or from a User Event. Context is received from the referring Action or established within the Action Set.

Please see the Actions section of this manual for a general description of all Actions as well as detailed information about each specific Execution or Control Action.

For User Events, context for the topmost event is exactly the same as the context at the point where the Action Manager was referenced as a result of the user activity. For each subsequent Action, context always starts over with the context of the topmost event. Within any Action, context may be modified by a “loop” Control Action.

For Scheduled Events, context is established within the Action Set being referenced.

For Action Sets, context may be passed in from the Action that called the Action Set, or it may be established independently.

Although dragging and dropping Actions is available, there are limitations to where something can be dropped. Generally speaking, Actions need to remain within the event or control structure within which they are created.