Class RuleAction
Common DataBase Connexity Table Manager Class This class factorize code for CommonDBChild and CommonDBRelation. Both classes themselves factorize and normalize the behaviour of all Child and Relations. As such, several elements are directly managed by these two classes since 0.84 : - Check: all can* methods (canCreate, canUpdate, canViewItem, canDeleteItem ...) are defined. - Update: when we try to update an attached element, we check if we change its parent item(s). If we change its parent(s), then we check if we can delete the item with previous parent(s) (cf. "check" before) AND we can create the item with the new parent(s). - Entity: Entity is automatically setted or updated when setting or changing an attached item. Thus, you don't have any more to worry about entities. (May be disable using $disableAutoEntityForwarding) - Log: when we create, update or delete an item, we update its parent(s)'s histories to notify them of the creation, update or deletion - Flying items : some items can be on the stock. For instance, before beeing plugged inside a computer, an Item_DeviceProcessor can be without any parent. It is now possible to define such items and transfer them from parent to parent.
The aim of the new check is that the rights on a Child or a Relation are driven by the parent(s): you can create, delete or update the item if and only if you can update its parent(s); you can view the item if and only if you can view its parent(s). Beware that it differs from the default behaviour of CommonDBTM: if you don't define canUpdate or canDelete, then it checks canCreate and by default canCreate returns false (thus, if you don't do anything, you don't have any right). A side effect is that if you define specific rights (see NetworkName::canCreate()) for your classes you must define all rights (canCreate, canView, canUpdate and canDelete).
- CommonGLPI
-
CommonDBTM
-
CommonDBConnexity
-
CommonDBChild
-
RuleAction
Warning:
You have to care of calling CommonDBChild or CommonDBRelation methods if you override their methods (for instance: call parent::prepareInputForAdd($input) if you define prepareInputForAdd). You can find an example with UserEmail::prepareInputForAdd($input).
Located at ruleaction.class.php
public
array
|
|
public
|
|
public
|
|
public static
Title
|
|
public
string
|
|
public
|
|
public
|
|
public
array
|
|
public
array
|
#
rawSearchOptions( )
Provides search options configuration. Do not rely directly on this, @see CommonDBTM::searchOptions instead. |
public static
string
|
|
public static
string
|
|
public
an
|
|
public
|
|
public static
|
|
public static
|
|
public static
|
|
public static
|
|
public
|
|
public
|
|
public
|
DONT_CHECK_ITEM_RIGHTS,
HAVE_SAME_RIGHT_ON_ITEM,
HAVE_VIEW_RIGHT_ON_ITEM
|
public static
string
|
$itemtype
|
#
"Rule"
|
public static
string
|
$items_id
|
#
'rules_id'
|
public
boolean
|
$dohistory
Flag to determine whether or not changes must be logged into history. |
#
true
|
public
boolean
|
$auto_message_on_action
Flag to determine whether or not automatic messages must be generated on actions. |
#
false
|
$checkParentRights,
$log_history_add,
$log_history_delete,
$log_history_lock,
$log_history_unlock,
$log_history_update,
$logs_for_parent,
$mustBeAttached
|
$canDeleteOnItemClean,
$disableAutoEntityForwarding
|
$displaylist,
$othertabs,
$showdebug,
$type
|