Beautiful Code [256]
# setSourceProjectRelated()
# This method returns the related tasks objects
getSourceProjectRelatedValue()
# This method is not generated in order to avoid an encapsulation break
# setSourceProjectRelatedValue()
You must be asking where the typical project domain attributes and behavior are. The answer for the attributes, in most cases, is that they are attributes of Movement and some other UBM classes, masked in the GUI with other names. In other cases, the attribute is implemented through a base category, with all the accessors automatically generated as expected.
One example of this is the task predecessors, a list of tasks that need to be executed before a given task—a very basic project management concept, not found on trade operations. This list is also implemented by a base category named predecessor, which links a task to its predecessor in a configurable way because the category takes care of all the code needed.
Workflows implement task behavior. Again, basic Movement and more specialized Order behavior is reused. These workflows manipulate the objects in a way that makes sense for project management, and include some scripts for doing so. Workflows make development easier because they are configurable, and the programmer needs to write scripts only for specific object manipulation.
Figure 21-5 shows the Task workflow. In each box, words in parentheses represent the state ID. Transitions with the _action suffix are trigged by GUI events; the others are internally trigged by workflow events. For each transition, it is possible to define pre-and post-scripts. These scripts are the ones that will manipulate the objects according to the business logic—in this case, the task execution logic. Task represents the planning view of the process, which essentially goes through planned, ordered, and confirmed states.
Figure 21-5. Task workflow
This workflow is the same as Order, but some scripts were changed according to project domain logic. As an example, here is the script order_validateData, which is called before every _action as follows:
Code View: Scroll / Show All
### This script check that necessary data exists on Task
# gets the task object in use
task = state_change.object
error_message = ''
message_list = []
# checks if the task is attached to some project or not
if task.getSource() is None:
message_list.append('No Source')
# if the initial date is null, but there is a final date, makes
# initialDate = finalDate
if task.getStartDate() is None and task.getStopDate() is not None:
task.setStartDate(task.getStopDate())
if task.getStartDate () is None:
message_list.append("No Date")
if task.getDestination() is None:
message_list.append('No Destination')
# for each contained object, filters the one that are movements.
# A typical return would be something like
#('Task Line', 'Sale Order Line', 'Purchase Order Line')
for line in task.objectValues(portal_type=task.getPortalOrderMovementTypeList ()):
# checks if all movements have a associated resource
if line.getResourceValue() is None:
message_list.append("No Resource for line with id: %s" % line.getId())
# if any error happened, raises a warning
if len(message_list) > 0:
raise ValidationFailed, "Warning: " + " --- ".join(message_list)
Figure 21-6 shows the Task Report workflow. It follows the same logic as the Delivery workflow, with some added scripts, such as taskReport_notifyAssignee, shown here.
Figure 21-6. Task Report workflow
task_report = state_change.object
# searches for the assigner for the task
source_person = task_report.getSourceValue(portal_type="Person")
# searches for the assignee
destination_person = task_report.getDestinationValue(portal_type="Person")
# get the assigner email
if source_person is not None:
from_email = destination_person.getDefaultEmailText()
email = source_person.getDefaultEmailValue()
if email is not None:
msg = """
# preformmated string with message plus task data goes here
"""
email.activate().send(from_url