Action Service Changes 1.3

cancel
Showing results for 
Search instead for 
Did you mean: 

Action Service Changes 1.3

resplin
Intermediate
0 0 1,234

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



Action Service1.3
Archived


Decoupled Actions and Rules


Why:


  • Decouples actions and rules
  • Allows actions to be saved in any location within the repository
  • Actions and rules can be easily reused.
  • Multiple rule types can be supported.
  • Allows for future support of rule sets and template actions.

Action model modifications


Action type:


  • remove executeAsynchronously attribute (moved to Rule type)
  • remove runAsUser attribute (not used)
  • remove runAsPassword attribute (not used)
  • add child association ownedActionItems (used to hold anonymous actions and conditions)
  • change conditions child association into an association
  • change compensatingAction child association into an association

CompensatingAction type:


  • change actions child association into an association

These types and aspects have been removed:


  • SavedActionFolder (type)
  • ActionExecutionDetails (type)
  • Actions (aspect)
  • ActionExecutionHistory (aspect)

Estimates:


  • Priority: Must
  • Estimate: 0.5 day

Action service API changes


  • Create an ActionRef class that is used as a reference to an action.  It contains the node reference to the action node, the title and description of the action.
  • The Action type extends ActionRef.
  • Change the CompositeAction class to work with ActionRef's rather than Action's.
  • Remove the methods for setting and getting the owning node and the methods for setting the asynchronous execution value from the Action class.
  • Add createAction overload:
Action createAction(ActionRef actionRef);

  • Modify the saveAction method:
/**
* Saves an action in the location specified.
*
* @param parentNodeRef   the parent node reference
* @param assocType       the assoc type qualified name
* @param assocName       the name of the assoc
* @param action          the action to save
* @return                a reference to the newly created action
*/
ActionRef saveAction(NodeRef parentNodeRef, QName assocType, QName assocName, Action action);


  • Add a updateAction method:
/*
* Updates the state of an action.
*/
ActionRef updateAction(Action action);

  • Add a getAction methods:
/**
* Get the populated action object from the action reference
*/
Action getAction(ActionRef actionRef);

/**
* Get the populated action objecgt from the action node reference
*/
Action getAction(NodeRef nodeRef);

  • Modify the removeAction action:
/**
* Removes a saved action from the repository.
*/
void removeAction(ActionRef actionRef);

  • Priority: Must
  • Estimate: 2/4 days
  • Dependencies: action model changes

Rule model modifications


RuleBase type:


  • An abstract base type for rule (and in the future ruleSet)
  • Contains attributes title and description.

Rule type:


  • Inherits from RuleBase. (rather than from CompositeAction)
  • A rule will have a (non child) association to the action or composite action that will be executed when the rule is triggered.
  • The ruleType attribute will be multi-values to support multiple rule types per rule.
  • A attribute to indicate whether the triggered action should be run asynchronously or not will be added.

Rules aspect:


  • Has a (non-child) association to one or more rule set.

Rule service API changes


Update Rule class:


  • Add methods to add, remove and get rule types.
  • Add methods to get/set related ActionRef.
  • Add methods to get/set value that indicates async execution of action.

Update RuleService class:


  • Add getRule method to get the rule from the rule node reference:
public Rule getRule(NodeRef ruleNodeRef);

public Rule getRule(RuleRef ruleRef);

  • Modify getRules method:
public List<RuleRef> getRules( ... );

  • Modify createRule to take no parameters:
public Rule createRule();

  • Add applyRule method:
public void applyRule(NodeRef nodeRef, Rule rule);

  • Add updateRule method:
public void updateRule(Rule rule);

  • Priority: Must
  • Estimate: 3/5 days
  • Dependancies: Action API update and models changes

Action/Rule service implementation changes


  • When a retrieving a rule or action, if the child action is not considered to be a child of the parent then an action reference is returned in place of a fully populated action. (Estimate: part of API changes)
  • Allow actions to be executed at the end of the transaction, before the transaction is committed.  This code can be removed from the Rule service and incorporated into the Action service. (Estimate: 1/2 days)

Patch implementation


  • Update all actions with the correct associations and child associations.
  • Move already saved actions into a system folder beneath the owning node, removing the non-existant actions aspect, or move all saved actions into a data dictionary location.
  • Create a composite action from every rule and create a new rule that references the composite action.  Setup the associations and child associations from the 'owning' nodeRef to the rule correctly.




  • Priority: Must
  • Estimate: 2/4 days
  • Dependencies: Action and rule model and API changes

Fallout


  • Web service API changes. (Estimate: 2 days)
  • UI changes. (Estimate: 1/2 days)

RuleSet support


RuleSet type:


  • Association to Rules.
  • Child association to Rules that are 'owned' by this rule set.

RuleSet class:


  • Extends RuleRef class.
  • Has add, get, remove methods to manipulate rules.  Works with rule reference allowing rule sets to be contained within rule sets.

RuleService API:


  • Add the following methods:
public RuleSet createRuleSet();

public RuleSet saveRuleSet(NodeRef parentNodeRef, QName assocType, QName assocName, RuleSet ruleSet);

public void deleteRuleSet(RuleSet ruleSet);

public RuleSet getRuleSet(NodeRef nodeRef);

public void applyRuleSet(NodeRef nodeRef, RuleSet ruleSet);

public void removeRuleSet(NodeRef nodeRef RuleSet ruleSet);

Dependencies:


  • Decoupling of actions and rules as described above.

Fallout:


  • UI to manage RuleSets and Rules
  • Web Service API updates

Estimates:


  • Priority: Must/Should
  • Estimate (excluding UI): 3/5 days

Re-apply rule(s)


Add the following methods to RuleService:

/**
* Triggers a list of rules against a provided list of nodes.
*
* @param nodeRefs  a list of nodes that the rules will trigger against
* @param rules     a list of rules to trigger
*/
public void triggerRules(List<NodeRef> nodeRefs, List<Rule> rules);

/**
* Triggers a rule set against a provided list of nodes.  If a list of rule types are provided, only rules
* with a type found in the list will be triggered.  If none are provided all rules in the set are triggered.
*
* @param nodeRefs  a list of nodes that the rule set will trigger against
* @param ruleSet   the rule set to trigger
* @param ruleTypes a list of rule types used to filter the rules that get triggered.
*/
public void triggerRules(List<NodeRef> nodeRefs, RuleSet ruleSet, List<String> ruleTypes);

  • Priority: Must
  • Estimate: 1/2 days
  • Dependencies: the introduction of ruleSets
  • Knock on effects:  UI, Web Service API

New rule types


Update rule type


Add a rule type that triggers when the content or meta-data of a node is updated.  This does not include creation.

This has been partially added, but at the moment the policy fires too frequently.


  • Priority: Must
  • Estimate: 2 days

Incomplete rule type


Add a rule type that triggers if the node is incomplete.  An incomplete node is one which has mandatory (required) attribute that have not been assigned a value.

This rule will be triggered by the update policy and check the meta-data of the node to check for completeness.


  • Priority: Must/Should
  • Estimate: 1 day
  • Dependencies: do we need to support the notion of a incomplete node in the dictionary before we can do this?

Ordering


Rule execution should be ordered:


  • Async rules are no ordered.
  • Inherited rules are done first in the correct order.
  • Remaining rules are ordered accordingly
  • Priority: Must
  • Estimate (excluding UI): 1/2 days

Sub-actions and conditions should be ordered:


  • Priority: Must
  • Estimate (excluding UI): 1 day

Copy and Transform action overwriting behaviour


  • Add attribute to copy and transform actions to specify whether the destination of the copy or transfer should be overwritten or not. 
  • If it should not be ovewriten then an exception is raised.
  • If the original is versionable then version the destination before copy or transform.
  • Priority: Must
  • Estimate (excluding UI): 1 day

New actions and conditions


Role condition:


  • Add a condition that succeeds if the current user has a role specified in the condition parameters.
  • Priority: Must
  • Estimate (excluding UI): 1 day

Delete aspect action:


  • Add an action to remove a specified action:
  • Priority: Must
  • Estimate: 1 day
  • Status: Complete

Action and rule set library support


  • Priority: Should/Could

Changes to workflow action


  •  ??

Supporting template actions


  • Priority: Should/Could

Action audit trail


  • Priority: Could