The Story that's driving the concrete, state data persisting Artisan class is as follows:
-
As an Artisan manager, I need to be able to manage (create, modify, and delete) artisans in the system, so that their statuses and information can be kept current.
As with the hms_artisan equivalent, this is about being able to manage the data, not the UI around that data management process. The various moving parts of any of the data objects in co_objects will involve the following:
-
The properties of the object type, which will originate with the corresponding Base class in hms_core.business_objects
-
The data persistence-related properties of all data objects in the system, provided or required by HMSMongoDataObject ...
