comparison modules/rules/rules.api.php @ 4:ce11bbd8f642

added modules
author danieleb <danielebarchiesi@me.com>
date Thu, 19 Sep 2013 10:38:44 +0100
parents
children
comparison
equal deleted inserted replaced
3:b28be78d8160 4:ce11bbd8f642
1 <?php
2
3 /**
4 * @file
5 * This file contains no working PHP code; it exists to provide additional
6 * documentation for doxygen as well as to document hooks in the standard
7 * Drupal manner.
8 */
9
10
11 /**
12 * @defgroup rules Rules module integrations.
13 *
14 * Module integrations with the rules module.
15 *
16 * The Rules developer documentation describes how modules can integrate with
17 * rules: http://drupal.org/node/298486.
18 */
19
20 /**
21 * @defgroup rules_hooks Rules' hooks
22 * @{
23 * Hooks that can be implemented by other modules in order to extend rules.
24 */
25
26 /**
27 * Define rules compatible actions.
28 *
29 * This hook is required in order to add a new rules action. It should be
30 * placed into the file MODULENAME.rules.inc, which gets automatically included
31 * when the hook is invoked.
32 *
33 * However, as an alternative to implementing this hook, class based plugin
34 * handlers may be provided by implementing RulesActionHandlerInterface. See
35 * the interface for details.
36 *
37 * @return
38 * An array of information about the module's provided rules actions.
39 * The array contains a sub-array for each action, with the action name as
40 * the key. Actions names may only contain lowercase alpha-numeric characters
41 * and underscores and should be prefixed with the providing module name.
42 * Possible attributes for each sub-array are:
43 * - label: The label of the action. Start capitalized. Required.
44 * - group: A group for this element, used for grouping the actions in the
45 * interface. Should start with a capital letter and be translated.
46 * Required.
47 * - parameter: (optional) An array describing all parameter of the action
48 * with the parameter's name as key. Each parameter has to be
49 * described by a sub-array with possible attributes as described
50 * afterwards, whereas the name of a parameter needs to be a lowercase,
51 * valid PHP variable name.
52 * - provides: (optional) An array describing the variables the action
53 * provides to the evaluation state with the variable name as key. Each
54 * variable has to be described by a sub-array with possible attributes as
55 * described afterwards, whereas the name of a parameter needs to be a
56 * lowercase, valid PHP variable name.
57 * - 'named parameter': (optional) If set to TRUE, the arguments will be
58 * passed as a single array with the parameter names as keys. This emulates
59 * named parameters in PHP and is in particular useful if the number of
60 * parameters can vary. Defaults to FALSE.
61 * - base: (optional) The base for action implementation callbacks to use
62 * instead of the action's name. Defaults to the action name.
63 * - callbacks: (optional) An array which allows to set specific function
64 * callbacks for the action. The default for each callback is the actions
65 * base appended by '_' and the callback name.
66 * - 'access callback': (optional) A callback which has to return whether the
67 * currently logged in user is allowed to configure this action. See
68 * rules_node_integration_access() for an example callback.
69 * Each 'parameter' array may contain the following properties:
70 * - label: The label of the parameter. Start capitalized. Required.
71 * - type: The rules data type of the parameter, which is to be passed to the
72 * action. All types declared in hook_rules_data_info() may be specified, as
73 * well as an array of possible types. Also lists and lists of a given type
74 * can be specified by using the notating list<integer> as introduced by
75 * the entity metadata module, see hook_entity_property_info(). The special
76 * keyword '*' can be used when all types should be allowed. Required.
77 * - bundles: (optional) An array of bundle names. When the specified type is
78 * set to a single entity type, this may be used to restrict the allowed
79 * bundles.
80 * - description: (optional) If necessary, a further description of the
81 * parameter.
82 * - options list: (optional) A callback that returns an array of possible
83 * values for this parameter. The callback has to return an array as used
84 * by hook_options_list(). For an example implementation see
85 * rules_data_action_type_options().
86 * - save: (optional) If this is set to TRUE, the parameter will be saved by
87 * rules when the rules evaluation ends. This is only supported for savable
88 * data types. If the action returns FALSE, saving is skipped.
89 * - optional: (optional) May be set to TRUE, when the parameter isn't
90 * required.
91 * - 'default value': (optional) The value to pass to the action, in case the
92 * parameter is optional and there is no specified value.
93 * - 'allow null': (optional) Usually Rules will not pass any NULL values as
94 * argument, but abort the evaluation if a NULL value is present. If set to
95 * TRUE, Rules will not abort and pass the NULL value through. Defaults to
96 * FALSE.
97 * - restriction: (optional) Restrict how the argument for this parameter may
98 * be provided. Supported values are 'selector' and 'input'.
99 * - default mode: (optional) Customize the default mode for providing the
100 * argument value for a parameter. Supported values are 'selector' and
101 * 'input'. The default depends on the required data type.
102 * - sanitize: (optional) Allows parameters of type 'text' to demand an
103 * already sanitized argument. If enabled, any user specified value won't be
104 * sanitized itself, but replacements applied by input evaluators are as
105 * well as values retrieved from selected data sources.
106 * - translatable: (optional) If set to TRUE, the provided argument value
107 * of the parameter is translatable via i18n String translation. This is
108 * applicable for textual parameters only, i.e. parameters of type 'text',
109 * 'token', 'list<text>' and 'list<token>'. Defaults to FALSE.
110 * - ui class: (optional) Allows overriding the UI class, which is used to
111 * generate the configuration UI of a parameter. Defaults to the UI class of
112 * the specified data type.
113 * - cleaning callback: (optional) A callback that input evaluators may use
114 * to clean inserted replacements; e.g. this is used by the token evaluator.
115 * - wrapped: (optional) Set this to TRUE in case the data should be passed
116 * wrapped. This only applies to wrapped data types, e.g. entities.
117 * Each 'provides' array may contain the following properties:
118 * - label: The label of the variable. Start capitalized. Required.
119 * - type: The rules data type of the variable. All types declared in
120 * hook_rules_data_info() may be specified. Types may be parametrized e.g.
121 * the types node<page> or list<integer> are valid.
122 * - save: (optional) If this is set to TRUE, the provided variable is saved
123 * by rules when the rules evaluation ends. Only possible for savable data
124 * types. Defaults to FALSE.
125 *
126 * The module has to provide an implementation for each action, being a
127 * function named as specified in the 'base' key or for the execution callback.
128 * All other possible callbacks are optional.
129 * Supported action callbacks by rules are defined and documented in the
130 * RulesPluginImplInterface. However any module may extend the action plugin
131 * based upon a defined interface using hook_rules_plugin_info(). All methods
132 * defined in those interfaces can be overridden by the action implementation.
133 * The callback implementations for those interfaces may reside in any file
134 * specified in hook_rules_file_info().
135 *
136 * @see hook_rules_file_info()
137 * @see rules_action_execution_callback()
138 * @see hook_rules_plugin_info()
139 * @see RulesPluginImplInterface
140 */
141 function hook_rules_action_info() {
142 return array(
143 'mail_user' => array(
144 'label' => t('Send a mail to a user'),
145 'parameter' => array(
146 'user' => array('type' => 'user', 'label' => t('Recipient')),
147 ),
148 'group' => t('System'),
149 'base' => 'rules_action_mail_user',
150 'callbacks' => array(
151 'validate' => 'rules_action_custom_validation',
152 'help' => 'rules_mail_help',
153 ),
154 ),
155 );
156 }
157
158 /**
159 * Define categories for Rules items, e.g. actions, conditions or events.
160 *
161 * Categories are similar to the previously used 'group' key in e.g.
162 * hook_rules_action_info(), but have a machine name and some more optional
163 * keys like a weight, or an icon.
164 *
165 * For best compatibility, modules may keep using the 'group' key for referring
166 * to categories. However, if a 'group' key and a 'category' is given the group
167 * will be treated as grouping in the given category (e.g. group "paypal" in
168 * category "commerce payment").
169 *
170 * @return
171 * An array of information about the module's provided categories.
172 * The array contains a sub-array for each category, with the category name as
173 * the key. Names may only contain lowercase alpha-numeric characters
174 * and underscores and should be prefixed with the providing module name.
175 * Possible attributes for each sub-array are:
176 * - label: The label of the category. Start capitalized. Required.
177 * - weight: (optional) A weight for sorting the category. Defaults to 0.
178 * - equals group: (optional) For BC, categories may be defined that equal
179 * a previsouly used 'group'.
180 * - icon: (optional) The file path of an icon to use, relative to the module
181 * or specified icon path. The icon should be a transparent SVG containing
182 * no colors (only #fff). See https://drupal.org/node/2090265 for
183 * instructions on how to create a suiting icon.
184 * Note that the icon is currently not used by Rules, however other UIs
185 * building upon Rules (like fluxkraft) do, and future releases of Rules
186 * might do as well. Consequently, the definition of an icon is optional.
187 * However, if both an icon font and icon is given, the icon is preferred.
188 * - icon path: (optional) The base path for the icon. Defaults to the
189 * providing module's directory.
190 * - icon font class: (optional) An icon font class referring to a suiting
191 * icon. Icon font class names should map to the ones as defined by Font
192 * Awesome, while themes might want to choose to provide another icon font.
193 * See http://fortawesome.github.io/Font-Awesome/cheatsheet/.
194 * - icon background color: (optional) The color used as icon background.
195 * Should have a high contrast to white. Defaults to #ddd.
196 */
197 function hook_rules_category_info() {
198 return array(
199 'rules_data' => array(
200 'label' => t('Data'),
201 'equals group' => t('Data'),
202 'weight' => -50,
203 ),
204 'fluxtwitter' => array(
205 'label' => t('Twitter'),
206 'icon font class' => 'icon-twitter',
207 'icon font background color' => '#30a9fd',
208 ),
209 );
210 }
211
212 /**
213 * Specify files containing rules integration code.
214 *
215 * All files specified in that hook will be included when rules looks for
216 * existing callbacks for any plugin. Rules remembers which callback is found in
217 * which file and automatically includes the right file before it is executing
218 * a plugin method callback. The file yourmodule.rules.inc is added by default
219 * and need not be specified here.
220 * This allows you to add new include files only containing functions serving as
221 * plugin method callbacks in any file without having to care about file
222 * inclusion.
223 *
224 * @return
225 * An array of file names without the file ending which defaults to '.inc'.
226 */
227 function hook_rules_file_info() {
228 return array('yourmodule.rules-eval');
229 }
230
231 /**
232 * Specifies directories for class-based plugin handler discovery.
233 *
234 * Implementing this hook is not a requirement, it is just one option to load
235 * the files containing the classes during discovery - see
236 * rules_discover_plugins().
237 *
238 * @return string|array
239 * A directory relative to the module directory, which holds the files
240 * containing rules plugin handlers, or multiple directories keyed by the
241 * module the directory is contained in.
242 * All files in those directories having a 'php' or 'inc' file extension will
243 * be loaded during discovery. Optionally, wildcards ('*') may be used to
244 * match multiple directories.
245 *
246 * @see rules_discover_plugins()
247 */
248 function hook_rules_directory() {
249 return 'lib/Drupal/fluxtwitter/Rules/*';
250 }
251
252 /**
253 * The execution callback for an action.
254 *
255 * It should be placed in any file included by your module or in a file
256 * specified using hook_rules_file_info().
257 *
258 * @param
259 * The callback gets arguments passed as described as parameter in
260 * hook_rules_action_info() as well as an array containing the action's
261 * configuration settings.
262 * @return
263 * The action may return an array containg parameter or provided variables
264 * with their names as key. This is used update the value of a parameter or to
265 * provdide the value for a provided variable.
266 * Apart from that any parameters which have the key 'save' set to TRUE will
267 * be remembered to be saved by rules unless the action returns FALSE.
268 * Conditions have to return a boolean value in any case.
269 *
270 * @see hook_rules_action_info()
271 * @see hook_rules_file_info()
272 */
273 function rules_action_execution_callback($node, $title, $settings) {
274 $node->title = $title;
275 return array('node' => $node);
276 }
277
278 /**
279 * Define rules conditions.
280 *
281 * This hook is required in order to add a new rules condition. It should be
282 * placed into the file MODULENAME.rules.inc, which gets automatically included
283 * when the hook is invoked.
284 *
285 * However, as an alternative to implementing this hook, class based plugin
286 * handlers may be provided by implementing RulesConditionHandlerInterface. See
287 * the interface for details.
288 *
289 * Adding conditions works exactly the same way as adding actions, with the
290 * exception that conditions can't provide variables and cannot save parameters.
291 * Thus the 'provides' attribute is not supported. Furthermore the condition
292 * implementation callback has to return a boolean value.
293 *
294 * @see hook_rules_action_info()
295 */
296 function hook_rules_condition_info() {
297 return array(
298 'rules_condition_text_compare' => array(
299 'label' => t('Textual comparison'),
300 'parameter' => array(
301 'text1' => array('label' => t('Text 1'), 'type' => 'text'),
302 'text2' => array('label' => t('Text 2'), 'type' => 'text'),
303 ),
304 'group' => t('Rules'),
305 ),
306 );
307 }
308
309 /**
310 * Define rules events.
311 *
312 * This hook is required in order to add a new rules event. It should be
313 * placed into the file MODULENAME.rules.inc, which gets automatically included
314 * when the hook is invoked.
315 * The module has to invoke the event when it occurs using rules_invoke_event().
316 * This function call has to happen outside of MODULENAME.rules.inc,
317 * usually it's invoked directly from the providing module but wrapped by a
318 * module_exists('rules') check.
319 *
320 * However, as an alternative to implementing this hook, class based event
321 * handlers may be provided by implementing RulesEventHandlerInterface. See
322 * the interface for details.
323 *
324 * @return
325 * An array of information about the module's provided rules events. The array
326 * contains a sub-array for each event, with the event name as the key. The
327 * name may only contain lower case alpha-numeric characters and underscores
328 * and should be prefixed with the providing module name. Possible attributes
329 * for each sub-array are:
330 * - label: The label of the event. Start capitalized. Required.
331 * - group: A group for this element, used for grouping the events in the
332 * interface. Should start with a capital letter and be translated.
333 * Required.
334 * - class: (optional) An event handler class implementing the
335 * RulesEventHandlerInterface. If none is specified the
336 * RulesEventDefaultHandler class will be used. While the default event
337 * handler has no settings, custom event handlers may be implemented to
338 * to make an event configurable. See RulesEventHandlerInterface.
339 * - access callback: (optional) An callback, which has to return whether the
340 * currently logged in user is allowed to configure rules for this event.
341 * Access should be only granted, if the user at least may access all the
342 * variables provided by the event.
343 * - help: (optional) A help text for rules reaction on this event.
344 * - variables: (optional) An array describing all variables that are
345 * available for elements reacting on this event. Each variable has to be
346 * described by a sub-array with the possible attributes:
347 * - label: The label of the variable. Start capitalized. Required.
348 * - type: The rules data type of the variable. All types declared in
349 * hook_rules_data_info() or supported by hook_entity_property_info() may
350 * be specified.
351 * - bundle: (optional) If the type is an entity type, the bundle of the
352 * entity.
353 * - description: (optional) A description for the variable.
354 * - 'options list': (optional) A callback that returns an array of possible
355 * values for this variable as specified for entity properties at
356 * hook_entity_property_info().
357 * - 'skip save': (optional) If the variable is saved after the event has
358 * occurred anyway, set this to TRUE. So rules won't save the variable a
359 * second time. Defaults to FALSE.
360 * - handler: (optional) A handler to load the actual variable value. This
361 * is useful for lazy loading variables. The handler gets all so far
362 * available variables passed in the order as defined. Also see
363 * http://drupal.org/node/884554.
364 * Note that for lazy-loading entities just the entity id may be passed
365 * as variable value, so a handler is not necessary in that case.
366 *
367 * @see rules_invoke_event()
368 */
369 function hook_rules_event_info() {
370 $items = array(
371 'node_insert' => array(
372 'label' => t('After saving new content'),
373 'group' => t('Node'),
374 'variables' => rules_events_node_variables(t('created content')),
375 ),
376 'node_update' => array(
377 'label' => t('After updating existing content'),
378 'group' => t('Node'),
379 'variables' => rules_events_node_variables(t('updated content'), TRUE),
380 ),
381 'node_presave' => array(
382 'label' => t('Content is going to be saved'),
383 'group' => t('Node'),
384 'variables' => rules_events_node_variables(t('saved content'), TRUE),
385 ),
386 'node_view' => array(
387 'label' => t('Content is going to be viewed'),
388 'group' => t('Node'),
389 'variables' => rules_events_node_variables(t('viewed content')) + array(
390 'view_mode' => array('type' => 'text', 'label' => t('view mode')),
391 ),
392 ),
393 'node_delete' => array(
394 'label' => t('After deleting content'),
395 'group' => t('Node'),
396 'variables' => rules_events_node_variables(t('deleted content')),
397 ),
398 );
399 // Specify that on presave the node is saved anyway.
400 $items['node_presave']['variables']['node']['skip save'] = TRUE;
401 return $items;
402 }
403
404 /**
405 * Define rules data types.
406 *
407 * This hook is required in order to add a new rules data type. It should be
408 * placed into the file MODULENAME.rules.inc, which gets automatically included
409 * when the hook is invoked.
410 * Rules builds upon the entity metadata module, thus to improve the support of
411 * your data in rules, make it an entity if possible and provide metadata about
412 * its properties and CRUD functions by integrating with the entity metadata
413 * module.
414 * For a list of data types defined by rules see rules_rules_core_data_info().
415 *
416 *
417 * @return
418 * An array of information about the module's provided data types. The array
419 * contains a sub-array for each data type, with the data type name as the
420 * key. The name may only contain lower case alpha-numeric characters and
421 * underscores and should be prefixed with the providing module name. Possible
422 * attributes for each sub-array are:
423 * - label: The label of the data type. Start uncapitalized. Required.
424 * - parent: (optional) A parent type may be set to specify a sub-type
425 * relationship, which will be only used for checking compatible types. E.g.
426 * the 'entity' data type is parent of the 'node' data type, thus a node may
427 * be also used for any action needing an 'entity' parameter. Can be set to
428 * any known rules data type.
429 * - ui class: (optional) Specify a class that is used to generate the
430 * configuration UI to configure parameters of this type. The given class
431 * must extend RulesDataUI and may implement the
432 * RulesDataDirectInputFormInterface in order to allow the direct data input
433 * configuration mode. For supporting selecting values from options lists,
434 * the UI class may implement RulesDataInputOptionsListInterface also.
435 * Defaults to RulesDataUI.
436 * - wrap: (optional) If set to TRUE, the data is wrapped internally using
437 * wrappers provided by the entity API module. This is required for entities
438 * and data structures to support selecting a property via the data selector
439 * and for intelligent saving.
440 * - is wrapped: (optional) In case the data wrapper is already wrapped when
441 * passed to Rules and Rules should not unwrap it when passing the data as
442 * argument, e.g. to an action, set this to TRUE. The default FALSE is fine
443 * in most cases.
444 * - wrapper class: (optional) Allows the specification of a custom wrapper
445 * class, which has to inherit from 'EntityMetadataWrapper'. If given Rules
446 * makes use of the class for wrapping the data of the given type. However
447 * note that if data is already wrapped when it is passed to Rules, the
448 * existing wrappers will be kept.
449 * For modules implementing identifiable data types being non-entites the
450 * class RulesIdentifiableDataWrapper is provided, which can be used as base
451 * for a custom wrapper class. See RulesIdentifiableDataWrapper for details.
452 * - property info: (optional) May be used for non-entity data structures to
453 * provide info about the data properties, such that data selectors via an
454 * entity metadata wrapper are supported. Specify an array as expected by
455 * the $info parameter of entity_metadata_wrapper().
456 * - creation callback: (optional) If 'property info' is given, an optional
457 * callback that makes use of the property info to create a new instance of
458 * this data type. Entities should use hook_entity_info() to specify the
459 * 'creation callback' instead, as utilized by the entity API module. See
460 * rules_action_data_create_array() for an example callback.
461 * - property defaults: (optional) May be used for non-entity data structures
462 * to to provide property info defaults for the data properties. Specify an
463 * array as expected by entity_metadata_wrapper().
464 * - group: (optional) A group for this element, used for grouping the data
465 * types in the interface. Should start with a capital letter and be
466 * translated.
467 * - token type: (optional) The type name as used by the token module.
468 * Defaults to the type name as used by rules. Use FALSE to let token ignore
469 * this type.
470 * - cleaning callback: (optional) A callback that input evaluators may use
471 * to clean inserted replacements; e.g. this is used by the token evaluator.
472 *
473 * @see entity_metadata_wrapper()
474 * @see hook_rules_data_info_alter()
475 * @see rules_rules_core_data_info()
476 */
477 function hook_rules_data_info() {
478 return array(
479 'node' => array(
480 'label' => t('content'),
481 'parent' => 'entity',
482 'group' => t('Node'),
483 ),
484 // Formatted text as used by in hook_entity_property_info() for text fields.
485 'text_formatted' => array(
486 'label' => t('formatted text'),
487 'ui class' => 'RulesDataUITextFormatted',
488 'wrap' => TRUE,
489 'property info' => entity_property_text_formatted_info(),
490 ),
491 );
492 }
493
494 /**
495 * Defines rules plugins.
496 *
497 * A rules configuration may consist of elements being instances of any rules
498 * plugin. This hook can be used to define new or to extend rules plugins.
499 *
500 * @return
501 * An array of information about the module's provided rules plugins. The
502 * array contains a sub-array for each plugin, with the plugin name as the
503 * key. The name may only contain lower case alpha-numeric characters,
504 * underscores and spaces and should be prefixed with the providing module
505 * name. Possible attributes for
506 * each sub-array are:
507 * - label: A label for the plugin. Start capitalized. Required only for
508 * components (see below).
509 * - class: The implementation class. Has to extend the RulesPlugin class.
510 * - embeddable: A container class in which elements of those plugin may be
511 * embedded via the UI or FALSE to disallow embedding it via the UI. This
512 * has no implications on the API level though. Common classes that are
513 * used here are RulesConditionContainer and RulesActionContainer.
514 * - component: If set to TRUE, the rules admin UI will list elements of those
515 * plugin in the components UI and allows the creation of new components
516 * based upon this plugin. Optional.
517 * - extenders: This allows one to specify faces extenders, which may be used
518 * to dynamically implement interfaces. Optional. All extenders specified
519 * here are setup automatically by rules once the object is created. To
520 * specify set this to an array, where the keys are the implemented
521 * interfaces pointing to another array with the keys:
522 * - class: The class of the extender, implementing the FacesExtender
523 * and the specified interface. Either 'class' or 'methods' has to exist.
524 * - methods: An array of callbacks that implement the methods of the
525 * interface where the method names are the keys and the callback names
526 * the values. There has to be a callback for each defined method.
527 * - file: An optional array describing the file to include when a method
528 * of the interface is invoked. The array entries known are 'type',
529 * 'module', and 'name' matching the parameters of module_load_include().
530 * Only 'module' is required as 'type' defaults to 'inc' and 'name' to
531 * NULL.
532 * - overrides: An optional array, which may be used to specify callbacks to
533 * override specific methods. For that the following keys are supported:
534 * - methods: As in the extenders array, but you may specify as many methods
535 * here as you like.
536 * - file: Optionally an array specifying a file to include for a method.
537 * For each method appearing in methods a file may be specified by using
538 * the method name as key and another array as value, which describes the
539 * file to include - looking like the file array supported by 'extenders'.
540 * - import keys: (optional) Embeddable plugins may specify an array of import
541 * keys, which the plugin make use for exporting. Defaults to the upper
542 * case plugin name, thus the key 'OR' in an export triggers the creation
543 * of the 'or' plugin. Note that only uppercase values are allowed, as
544 * lower case values are treated as action or condition exports.
545 *
546 * @see class RulesPlugin
547 * @see hook_rules_plugin_info_alter()
548 */
549 function hook_rules_plugin_info() {
550 return array(
551 'or' => array(
552 'label' => t('Condition set (OR)'),
553 'class' => 'RulesOr',
554 'embeddable' => 'RulesConditionContainer',
555 'component' => TRUE,
556 'extenders' => array(
557 'RulesPluginUIInterface' => array(
558 'class' => 'RulesConditionContainerUI',
559 ),
560 ),
561 ),
562 'rule' => array(
563 'class' => 'Rule',
564 'embeddable' => 'RulesRuleSet',
565 'extenders' => array(
566 'RulesPluginUIInterface' => array(
567 'class' => 'RulesRuleUI',
568 ),
569 ),
570 'import keys' => array('DO', 'IF'),
571 ),
572 );
573 }
574
575 /**
576 * Declare provided rules input evaluators.
577 *
578 * The hook implementation should be placed into the file MODULENAME.rules.inc,
579 * which gets automatically included when the hook is invoked.
580 * For implementing an input evaluator a class has to be provided which
581 * extends the abstract RulesDataInputEvaluator class. Therefore the abstract
582 * methods prepare() and evaluate() have to be implemented, as well as access()
583 * and help() could be overridden in order to control access permissions or to
584 * provide some usage help.
585 *
586 * @return
587 * An array of information about the module's provided input evaluators. The
588 * array contains a sub-array for each evaluator, with the evaluator name as
589 * the key. The name may only contain lower case alpha-numeric characters and
590 * underscores and should be prefixed with the providing module name. Possible
591 * attributes for each sub-array are:
592 * - class: The implementation class, which has to extend the
593 * RulesDataInputEvaluator class. Required.
594 * - weight: A weight for controlling the evaluation order of multiple
595 * evaluators. Required.
596 * - type: Optionally, the data types for which the input evaluator should be
597 * used. Defaults to 'text'. Multiple data types may be specified using an
598 * array.
599 *
600 * @see class RulesDataInputEvaluator
601 * @see hook_rules_evaluator_info_alter()
602 */
603 function hook_rules_evaluator_info() {
604 return array(
605 'token' => array(
606 'class' => 'RulesTokenEvaluator',
607 'type' => array('text', 'uri'),
608 'weight' => 0,
609 ),
610 );
611 }
612
613 /**
614 * Declare provided rules data processors.
615 *
616 * The hook implementation should be placed into the file MODULENAME.rules.inc,
617 * which gets automatically included when the hook is invoked.
618 * For implementing a data processors a class has to be provided which
619 * extends the abstract RulesDataProcessor class. Therefore the abstract
620 * method process() has to be implemented, but also the methods form() and
621 * access() could be overridden in order to provide a configuration form or
622 * to control access permissions.
623 *
624 * @return
625 * An array of information about the module's provided data processors. The
626 * array contains a sub-array for each processor, with the processor name as
627 * the key. The name may only contain lower case alpha-numeric characters and
628 * underscores and should be prefixed with the providing module name, whereas
629 * 'select' is reserved as well.
630 * Possible attributes for each sub-array are:
631 * - class: The implementation class, which has to extend the
632 * RulesDataProcessor class. Required.
633 * - weight: A weight for controlling the processing order of multiple data
634 * processors. Required.
635 * - type: Optionally, the data types for which the data processor should be
636 * used. Defaults to 'text'. Multiple data types may be specified using an
637 * array.
638 *
639 * @see class RulesDataProcessor
640 * @see hook_rules_data_processor_info_alter()
641 */
642 function hook_rules_data_processor_info() {
643 return array(
644 'date_offset' => array(
645 'class' => 'RulesDateOffsetProcessor',
646 'type' => 'date',
647 'weight' => -2,
648 ),
649 );
650 }
651
652 /**
653 * Alter rules compatible actions.
654 *
655 * The implementation should be placed into the file MODULENAME.rules.inc, which
656 * gets automatically included when the hook is invoked.
657 *
658 * @param $actions
659 * The items of all modules as returned from hook_rules_action_info().
660 *
661 * @see hook_rules_action_info().
662 */
663 function hook_rules_action_info_alter(&$actions) {
664 // The rules action is more powerful, so hide the core action
665 unset($actions['rules_core_node_assign_owner_action']);
666 // We prefer handling saving by rules - not by the user.
667 unset($actions['rules_core_node_save_action']);
668 }
669
670 /**
671 * Alter rules conditions.
672 *
673 * The implementation should be placed into the file MODULENAME.rules.inc, which
674 * gets automatically included when the hook is invoked.
675 *
676 * @param $conditions
677 * The items of all modules as returned from hook_rules_condition_info().
678 *
679 * @see hook_rules_condition_info()
680 */
681 function hook_rules_condition_info_alter(&$conditions) {
682 // Change conditions.
683 }
684
685 /**
686 * Alter rules events.
687 *
688 * The implementation should be placed into the file MODULENAME.rules.inc, which
689 * gets automatically included when the hook is invoked.
690 *
691 * @param $events
692 * The items of all modules as returned from hook_rules_event_info().
693 *
694 * @see hook_rules_event_info().
695 */
696 function hook_rules_event_info_alter(&$events) {
697 // Change events.
698 }
699
700 /**
701 * Alter rules data types.
702 *
703 * The implementation should be placed into the file MODULENAME.rules.inc, which
704 * gets automatically included when the hook is invoked.
705 *
706 * @param $data_info
707 * The items of all modules as returned from hook_rules_data_info().
708 *
709 * @see hook_rules_data_info()
710 */
711 function hook_rules_data_info_alter(&$data_info) {
712 // Change data types.
713 }
714
715 /**
716 * Alter rules plugin info.
717 *
718 * The implementation should be placed into the file MODULENAME.rules.inc, which
719 * gets automatically included when the hook is invoked.
720 *
721 * @param $plugin_info
722 * The items of all modules as returned from hook_rules_plugin_info().
723 *
724 * @see hook_rules_plugin_info()
725 */
726 function hook_rules_plugin_info_alter(&$plugin_info) {
727 // Change plugin info.
728 }
729
730 /**
731 * Alter rules input evaluator info.
732 *
733 * The implementation should be placed into the file MODULENAME.rules.inc, which
734 * gets automatically included when the hook is invoked.
735 *
736 * @param $evaluator_info
737 * The items of all modules as returned from hook_rules_evaluator_info().
738 *
739 * @see hook_rules_evaluator_info()
740 */
741 function hook_rules_evaluator_info_alter(&$evaluator_info) {
742 // Change evaluator info.
743 }
744
745 /**
746 * Alter rules data_processor info.
747 *
748 * The implementation should be placed into the file MODULENAME.rules.inc, which
749 * gets automatically included when the hook is invoked.
750 *
751 * @param $processor_info
752 * The items of all modules as returned from hook_rules_data_processor_info().
753 *
754 * @see hook_rules_data_processor_info()
755 */
756 function hook_rules_data_processor_info_alter(&$processor_info) {
757 // Change processor info.
758 }
759
760 /**
761 * Act on rules configuration being loaded from the database.
762 *
763 * This hook is invoked during rules configuration loading, which is handled
764 * by entity_load(), via classes RulesEntityController and EntityCRUDController.
765 *
766 * @param $configs
767 * An array of rules configurations being loaded, keyed by id.
768 */
769 function hook_rules_config_load($configs) {
770 $result = db_query('SELECT id, foo FROM {mytable} WHERE id IN(:ids)', array(':ids' => array_keys($configs)));
771 foreach ($result as $record) {
772 $configs[$record->id]->foo = $record->foo;
773 }
774 }
775
776 /**
777 * Respond to creation of a new rules configuration.
778 *
779 * This hook is invoked after the rules configuration is inserted into the
780 * the database.
781 *
782 * @param RulesPlugin $config
783 * The rules configuration that is being created.
784 */
785 function hook_rules_config_insert($config) {
786 db_insert('mytable')
787 ->fields(array(
788 'nid' => $config->id,
789 'plugin' => $config->plugin,
790 ))
791 ->execute();
792 }
793
794 /**
795 * Act on a rules configuration being inserted or updated.
796 *
797 * This hook is invoked before the rules configuration is saved to the
798 * database.
799 *
800 * @param RulesPlugin $config
801 * The rules configuration that is being inserted or updated.
802 */
803 function hook_rules_config_presave($config) {
804 if ($config->id && $config->owner == 'your_module') {
805 // Add custom condition.
806 $config->conditon(/* Your condition */);
807 }
808 }
809
810 /**
811 * Respond to updates to a rules configuration.
812 *
813 * This hook is invoked after the configuration has been updated in the
814 * database.
815 *
816 * @param RulesPlugin $config
817 * The rules configuration that is being updated.
818 */
819 function hook_rules_config_update($config) {
820 db_update('mytable')
821 ->fields(array('plugin' => $config->plugin))
822 ->condition('id', $config->id)
823 ->execute();
824 }
825
826 /**
827 * Respond to rules configuration deletion.
828 *
829 * This hook is invoked after the configuration has been removed from the
830 * database.
831 *
832 * @param RulesPlugin $config
833 * The rules configuration that is being deleted.
834 */
835 function hook_rules_config_delete($config) {
836 db_delete('mytable')
837 ->condition('id', $config->id)
838 ->execute();
839 }
840
841 /**
842 * Respond to rules configuration execution.
843 *
844 * This hook is invoked right before the rules configuration is executed.
845 *
846 * @param RulesPlugin $config
847 * The rules configuration that is being executed.
848 */
849 function hook_rules_config_execute($config) {
850
851 }
852
853 /**
854 * Define default rules configurations.
855 *
856 * This hook is invoked when rules configurations are loaded. The implementation
857 * should be placed into the file MODULENAME.rules_defaults.inc, which gets
858 * automatically included when the hook is invoked.
859 *
860 * @return
861 * An array of rules configurations with the configuration names as keys.
862 *
863 * @see hook_default_rules_configuration_alter()
864 * @see hook_rules_config_defaults_rebuild()
865 */
866 function hook_default_rules_configuration() {
867 $rule = rules_reaction_rule();
868 $rule->label = 'example default rule';
869 $rule->active = FALSE;
870 $rule->event('node_update')
871 ->condition(rules_condition('data_is', array('data:select' => 'node:status', 'value' => TRUE))->negate())
872 ->condition('data_is', array('data:select' => 'node:type', 'value' => 'page'))
873 ->action('drupal_message', array('message' => 'A node has been updated.'));
874
875 $configs['rules_test_default_1'] = $rule;
876 return $configs;
877 }
878
879 /**
880 * Alter default rules configurations.
881 *
882 * The implementation should be placed into the file
883 * MODULENAME.rules_defaults.inc, which gets automatically included when the
884 * hook is invoked.
885 *
886 * @param $configs
887 * The default configurations of all modules as returned from
888 * hook_default_rules_configuration().
889 *
890 * @see hook_default_rules_configuration()
891 */
892 function hook_default_rules_configuration_alter(&$configs) {
893 // Add custom condition.
894 $configs['foo']->condition('bar');
895 }
896
897 /**
898 * Act after rebuilding default configurations.
899 *
900 * This hook is invoked by the entity module after default rules configurations
901 * have been rebuilt; i.e. defaults have been saved to the database.
902 *
903 * @param $rules_configs
904 * The array of default rules configurations which have been inserted or
905 * updated, keyed by name.
906 * @param $originals
907 * An array of original rules configurations keyed by name; i.e. the rules
908 * configurations before the current defaults have been applied. For inserted
909 * rules configurations no original is available.
910 *
911 * @see hook_default_rules_configuration()
912 * @see entity_defaults_rebuild()
913 */
914 function hook_rules_config_defaults_rebuild($rules_configs, $originals) {
915 // Once all defaults have been rebuilt, update all i18n strings at once. That
916 // way we build the rules cache once the rebuild is complete and avoid
917 // rebuilding caches for each updated rule.
918 foreach ($rules_configs as $name => $rule_config) {
919 if (empty($originals[$name])) {
920 rules_i18n_rules_config_insert($rule_config);
921 }
922 else {
923 rules_i18n_rules_config_update($rule_config, $originals[$name]);
924 }
925 }
926 }
927
928 /**
929 * Alter rules components before execution.
930 *
931 * This hooks allows altering rules components before they are cached for later
932 * re-use. Use this hook only for altering the component in order to prepare
933 * re-use through rules_invoke_component() or the provided condition/action.
934 * Note that this hook is only invoked for any components cached for execution,
935 * but not for components that are programmatically created and executed on the
936 * fly (without saving them).
937 *
938 * @param $plugin
939 * The name of the component plugin.
940 * @param $component
941 * The component that is to be cached.
942 *
943 * @see rules_invoke_component()
944 */
945 function hook_rules_component_alter($plugin, RulesPlugin $component) {
946
947 }
948
949 /**
950 * Alters event sets.
951 *
952 * This hooks allows altering rules event sets, which contain all rules that are
953 * triggered upon a specific event. Rules internally caches all rules associated
954 * to an event in an event set, which is cached for fast evaluation. This hook
955 * is invoked just before any event set is cached, thus it allows altering of
956 * the to be executed rules without the changes to appear in the UI, e.g. to add
957 * a further condition to some rules.
958 *
959 * @param $event_name
960 * The name of the event.
961 * @param $event_set
962 * The event set that is to be cached.
963 *
964 * @see rules_invoke_event()
965 */
966 function hook_rules_event_set_alter($event_name, RulesEventSet $event_set) {
967
968 }
969
970 /**
971 * D6 to D7 upgrade procedure hook for mapping action or condition names.
972 *
973 * If for a module the action or condition name changed since Drupal 6, this
974 * "hook" can be implemented in order to map to the new name of the action or
975 * condition.
976 *
977 * This is no real hook, but a callback that is invoked for each Drupal 6
978 * action or condition that is to be upgraded to Drupal 7. E.g. the function
979 * name called for the action "rules_action_set_node_title" would be
980 * "rules_action_set_node_title_upgrade_map_name".
981 *
982 * @param $element
983 * The element array of a configured condition or action which is to be
984 * upgraded.
985 * @return
986 * The name of the action or condition which should be used.
987 */
988 function hook_rules_action_base_upgrade_map_name($element) {
989 return 'data_set';
990 }
991
992 /**
993 * D6 to D7 upgrade procedure hook for mapping action or condition configuration.
994 *
995 * During upgrading Drupal 6 rule configurations to Drupal 7 Rules is taking
996 * care of upgrading the configuration of all known parameters, which only works
997 * if the parameter name has not changed.
998 * If something changed, this callback can be used to properly apply the
999 * configruation of the Drupal 6 action ($element) to the Drupal 7 version
1000 * ($target).
1001 *
1002 * This is no real hook, but a callback that is invoked for each Drupal 6
1003 * action or condition that is to be upgraded to Drupal 7. E.g. the function
1004 * name called for the action "rules_action_set_node_title" would be
1005 * "rules_action_set_node_title_upgrade".
1006 *
1007 * @param $element
1008 * The element array of a configured condition or action which is to be
1009 * upgraded.
1010 * @param $target
1011 * The Drupal 7 version of the configured element.
1012 *
1013 * @see hook_rules_element_upgrade_alter()
1014 */
1015 function hook_rules_action_base_upgrade($element, RulesPlugin $target) {
1016 $target->settings['data:select'] = $element['#settings']['#argument map']['node'] . ':title';
1017 $target->settings['value'] = $element['#settings']['title'];
1018 }
1019
1020 /**
1021 * D6 to D7 upgrade procedure hook for mapping action or condition configuration.
1022 *
1023 * A alter hook that is called after the action/condition specific callback for
1024 * each element of a configuration that is upgraded.
1025 *
1026 * @param $element
1027 * The element array of a configured condition or action which is to be
1028 * upgraded.
1029 * @param $target
1030 * The Drupal 7 version of the configured element.
1031 *
1032 * @see hook_rules_action_base_upgrade()
1033 */
1034 function hook_rules_element_upgrade_alter($element, $target) {
1035
1036 }
1037
1038 /**
1039 * Allows modules to alter or to extend the provided Rules UI.
1040 *
1041 * Use this hook over the regular hook_menu_alter() as the Rules UI is re-used
1042 * and embedded by modules. See rules_ui().
1043 *
1044 * @param $items
1045 * The menu items to alter.
1046 * @param $base_path
1047 * The base path of the Rules UI.
1048 * @param $base_count
1049 * The count of the directories contained in the base path.
1050 */
1051 function hook_rules_ui_menu_alter(&$items, $base_path, $base_count) {
1052 $items[$base_path . '/manage/%rules_config/schedule'] = array(
1053 'title callback' => 'rules_get_title',
1054 'title arguments' => array('Schedule !plugin "!label"', $base_count + 1),
1055 'page callback' => 'drupal_get_form',
1056 'page arguments' => array('rules_scheduler_schedule_form', $base_count + 1, $base_path),
1057 'access callback' => 'rules_config_access',
1058 'access arguments' => array('update', $base_count + 1),
1059 'file' => 'rules_scheduler.admin.inc',
1060 'file path' => drupal_get_path('module', 'rules_scheduler'),
1061 );
1062 }
1063
1064 /**
1065 * Control access to Rules configurations.
1066 *
1067 * Modules may implement this hook if they want to have a say in whether or not
1068 * a given user has access to perform a given operation on a Rules
1069 * configuration.
1070 *
1071 * @param $op
1072 * The operation being performed. One of 'view', 'create', 'update' or
1073 * 'delete'.
1074 * @param $rules_config
1075 * (optional) A Rules configuration to check access for. If nothing is given,
1076 * access for all Rules configurations is determined.
1077 * @param $account
1078 * (optional) The user to check for. If no account is passed, access is
1079 * determined for the current user.
1080 * @return boolean
1081 * Return TRUE to grant access, FALSE to explicitly deny access. Return NULL
1082 * or nothing to not affect the operation.
1083 * Access is granted as soon as a module grants access and no one denies
1084 * access. Thus if no module explicitly grants access, access will be denied.
1085 *
1086 * @see rules_config_access()
1087 */
1088 function hook_rules_config_access($op, $rules_config = NULL, $account = NULL) {
1089 // Instead of returning FALSE return nothing, so others still can grant
1090 // access.
1091 if (isset($rules_config) && $rules_config->owner == 'mymodule' && user_access('my modules permission')) {
1092 return TRUE;
1093 }
1094 }
1095
1096 /**
1097 * @}
1098 */