The first thing we thought about in creating the Project BT was the main project class. Initially, instead of creating a new class, we decided to simply use Order itself, without change. But after some time, we realized that the business definitions for an order and a project are so different that we should simply create Project as a subclass of Order, without any new code in it, just for the sake of separating concerns. In this design, a project is an object that is described by a series of goals or milestones with one or more tasks associated with each of them.
Then, we had to decide how to implement task management since
there are differences between a project and a trade operation. The first
thing to consider is that tasks can occur outside projects—for instance,
in production planning. Therefore, we consider a task as a composition
of task lines, or smaller activities inside a task. In that way, we
decouple tasks from projects, allowing them to be used in other
situations, while keeping the relation with Project through
destination_project base categories.
Tasks are implemented through configuration, as we did for Task Report Line in Figure 21-2, with the difference of using Order as a metaclass. The creation of a task associated with a project is shown here:
# Add a task in task_module. Context represents the currentproject object. context_obj = context.getObject() # newContent is an ERP5 API method that creates a new content. task ...