-
Feature Request
-
Resolution: Fixed
-
L3 - Default
-
None
It is already possible to register a listener on a task that is notified for
CREATE, ASSIGNMENT, COMPLETE, DELETE events. However, it is not yet possible to get notified about general updates like for instance a change in the duedate.
The idea behind this feature request is to provide a listener that can be registered for UPDATE events and is triggered for all changes that are made to the task except creation and deletion
This is the controller panel for Smart Panels app
[CAM-10254] Task listener for UPDATE Events
Design Decisions:
Task Lifecycle:
- create_task --> STATE_CREATED <-- update|assign --> STATE_CREATED
- STATE_CREATED – complete_task --> STATE_COMPLETED
- STATE_CREATED – delete_task --> STATE_DELETED
- Task State is maintained in-memory;
- Task Events are fired depending on TaskState and property changes;
- Task State changing actions are invoked by explicitly passing the new state when dispatching events. They map to the following internal, TaskEntity methods:
- TaskEntity.insert() -> TaskState.CREATED,
- TaskEntity.complete() -> TaskState.COMPLETED,
- TaskEntity.delete() -> TaskState.DELETED;
- Actions that update the task state (ex. property changing commands) do not pass TaskState information. The Task Events that should be fired are determined by the changed properties. This results in the following:
- Update events are fired when, at least, a single Task property is changed,
- Property changes during the create phase (before STATE_CREATED) do not fire an Update Event. However, an Assignment Event is fired during the create phase, if the assignee property is set (to maintain backward compatibility);
For future development of Task commands, we should maintain a pattern:
- State changing actions always call dispatchLifecycleEvents(TaskState) within TaskEntity i.e. the events are dispatched implicitly when the appropriate (action) method is invoked; This ensures that the Task State can't be externally modified.
- Task updating actions always call dispatchLifecycleEvents() explicitly, after the desired properties are updated. This ensures that the updates are accumulated, and the developer has control over how many events will be fired.
Notes on the new documentation:
In the Delegation Code docs, it is stated that the ASSIGNMENT event is fired before the CREATE event intentionally. I could only track the changes there until CAM-1276 and CAM-1283 (and ACT-506), but couldn't find the reason why it was done like this.
thorben.lindhauer I don't see a problem with what you propose.