One of the issues that have been encountered since actions were initially introduced is the portability of actions to a different SharePoint site. When a solution is moved to another site, as is the case when a solution template is created and then utilized, or moved from a development environment to a production one, there is a need to enable the actions referenced by the solution to be used with as little modification as possible. There is also the question of how to make action definitions reusable across multiple sites and solutions.
To address these needs and clarify exactly which lists and items will be affected by actions, two features are available:
•The Actions Wizard contains properties that allow you to identify whether the action should be executed against a specific hard-coded list, or a list with the same name in the site where the action is executed.
•Global Links allow you to define a named variable that represents a URL that you identify. When a change needs to be made, you can update the link in a single location, rather than updating every single action definition that references the URL. For example, say you define a Global Link and call it “Internet-Contacts.” You can use that Global Link in any number of action definitions. If you ever need to update that link, you can simply go to Global Links Manager, make the necessary changes, and the changes will take effect on all actions that reference that link. You don’t have to update the Global Link in every single instance where it is referenced. See Chapter 10 for details on the Global Links Manager.
The Actions Wizard interface offers the following options on the Data Source Selection page:
•Static – Select this option if the action should always be executed against the specific model list identified on the Model List/Library Selection page.
•Relative – Select this option if the action should be executed against a list in whatever site the action is executed from. The action will look for a list with the same name in that site. In the example used for the Create List Item action described above, if this option were selected, the action would be run against the Tasks list in the site where the action is run.
o If you use this option, it is a good idea to make sure all columns referenced by the action definition exist in the corresponding list where the action is executed. If any columns referenced by the action definition do not exist in that list, the action will fail.
•User Selects Destination – When the action is executed, the end user identifies the list to be affected by the action.
With these options, action definitions are portable, reusable, and easy to administer. Consider creating a central library of actions that can be referenced throughout the entire workplace. For example, you could create an “Add New Announcement” action in a central library, configure it to use the “Use List Relative to Site Where Action is Run” option, and use it in any number of solutions. When the action is executed and a new announcement is created, it will always be created in the Announcements list in the site where the action is run. All you need to do is make sure the columns referenced by the action exist in each of the Announcements lists.
Another very reusable, powerful action definition that could be saved in a central actions library is an Email action. You could define the action to send a custom email, so the user executing the action determines the content and recipient(s). Create the action definition once and use it any number of solutions. If the action ever needs to be updated, the update can be made in just one place, but affect all of the sites that reference the action. It’s not just reusable, it’s easier to ensure consistency.
This section describes some of the portability issues surrounding action definitions.
There are no portability issues for this type of action, beyond the issues stated for the individual action types that are chained together.
When creating a Create List Item action definition, you have the option to select static values from choice fields and multi-choice fields. If you do this and the selected value does not exist in the Choices collection for that field in the selected Grid or Calendar Display item, the action will fail.
This type of action is not tied to a specific list. The model list you identify in the action definition is only used to determine the columns that can be modified by the action. As long as the list item in the Grid or Calendar Display contains the column(s) identified in the action definition, the action will run.
For example, say you create an action and select a list that has a Title column. You type My New Title in the Title field when defining the action and leave all of the other available columns blank. This action can be run on any list item that has a Title field. If you also entered a value in the Description column, the action could only be executed against list items that contain both a Title and Description column.
This type of action is not portable. The current version does not support relative URLs for navigation.
There are several ways to configure actions, depending on whether and how you want to use them in multiple solutions and locations.
•You can create a central actions library and save the action(s) there. (Use the Actions Library list template included in the CorasWorks Platform download, in the “Lists and Libraries” folder.) Use Global Links to point to that library. As long as Central Configuration is enabled, the action will always be accessible.
•If you want to ensure that an action is always executed against a specific list in a specific URL, select the Static option on the Data Source Selection page when you create the action definition. CorasWorks calls actions that are configured in this way “re-usable.” They are hard-coded to reference a specific list.
•If you want the action to be executed against a list in the site where the Grid or Calendar Display is used, select the Relative option when you create the action definition. This will look for the list that is named in the action definition, in whatever site the action happens to be run from. CorasWorks calls actions that are configured in this way “portable.” They can be used in any site, as long as they contain the list named in the action definition, and as long as that list contains the columns referenced in the action.