[ADD] location, territory, branch, district, region #27
Conversation
max3903
force-pushed
the
11.0-fix-location
branch
from
6dec136 to
d0dd06d
Compare
|
|
||
| class Branch(models.Model): | ||
| _name = 'branch' | ||
| _description = 'branch' |
There was a problem hiding this comment.
I think this overlaps with hr.department.
That's what I'm using today for the same purpose.
There was a problem hiding this comment.
@dreispt The idea behind branch is mostly where the company has offices. Department is not necessarily geographically centralized...
| _description = 'branch' | ||
|
|
||
| name = fields.Char(string='Name') | ||
| district_id = fields.Many2one('district', string='District') |
There was a problem hiding this comment.
If we add a partner_id Address field to the Branch/Department, we automatically have a full address.
If we need additional fields for it, modules like base_location would do that for us.
| _description = 'District' | ||
|
|
||
| name = fields.Char(string='Name') | ||
| region_id = fields.Many2one('region', string='Region') |
There was a problem hiding this comment.
Instead of the fixed District -> Region -> ... multimodel fixed structure, we could have a flexible single model hierarchy structure. We could even include "Branch" and "Territory" as hierarchy layers, and avoid forcing a dependency on HR (it would then become an optional link).
fieldservice/models/fsm_location.py
Outdated
| @@ -9,6 +11,13 @@ class FSMLocation(models.Model): | |||
| _inherits = {'res.partner': 'partner_id'} | |||
There was a problem hiding this comment.
New style delegation inheritance: remove _inherits and instead add delegage=True on the partner_id field.
fieldservice/models/location.py
Outdated
|
|
||
| name = fields.Char(string='Name') | ||
| complete_name = fields.Char("Full Location Name", | ||
| compute='_compute_complete_name', store=True) |
| ondelete='restrict') | ||
| notes = fields.Html(string='Notes') | ||
| parent_left = fields.Integer('Left Parent', index=True) | ||
| parent_right = fields.Integer('Right Parent', index=True) |
There was a problem hiding this comment.
I think these are not used anymore, but I need to check (maybe on v12 only)
| building = fields.Char(string='Building', size=35) | ||
| floor = fields.Char(string='Floor', size=35) | ||
| unit = fields.Char(string='Unit', size=35) | ||
| room = fields.Char(string='Room', size=35) |
There was a problem hiding this comment.
These building/floor/room details don't need to be structured data.
When needed they can perfectly be included in the Location's name or Description.
There was a problem hiding this comment.
@dreispt that's why we removed them.
|
Can we have the Branch /Territory hierarchy instead? |
|
I like where this is going, but from reading the code and from a user's perspective the location model is confusingly named when we have already established the fsm_location model. As @wolfhall suggested in #22 the newer location model aims to represent a specific point of service within the fsm_location, so could we rename it service_point or something similar? That being said, wouldn't we have a relationship of one fsm_location to many service_points? Each service_point is unique to that fsm_location. The configuration area could establish multiple service_point_types that create the hierarchy of service_points within the fsm_location others have mentioned needing.
|
Fixing comments on #22