To guarantee that Locations can always be uniquely identified by a single human-readable field, ideally name. This is an extension of LOCATION_NAME_AS_NATURAL_KEY (#3977) to become an enforced part of the core data model.
So that ...
Users cannot enter ambiguous (non-unique) Location names in the database, ever.
App developers can consistently rely on Location.name being a unique identifier of a Location, without needing an alternative approach (i.e. natural-key/composite-key) to handle environments where LOCATION_NAME_AS_NATURAL_KEY is not set.
I know this is done when...
Location.name is changed to unique=True
Data migrations are provided to convert non-globally-unique location names to unique ones, ideally by walking up the Location tree as many levels as needed to guarantee uniqueness and concatenating parent names together as needed (i.e. so that a non-unique "Room 101" becomes "Atlanta: Building 100: Floor 1: Room 101" rather than something generic like "Room 101 (2)").
Optional - Feature groups this request pertains to.
[ ] Automation
[ ] Circuits
[X] DCIM
[ ] IPAM
[ ] Misc (including Data Sources)
[X] Organization
[ ] Plugins (and other Extensibility)
[ ] Security (Secrets, etc)
[ ] Image Management
[ ] UI/UX
[ ] Documentation
[ ] Other (not directly a platform feature)
Database Changes
As this is a breaking change to the data model it will need to be done on a major release boundary.
As ...
Dan - Data Owner
I want ...
To guarantee that Locations can always be uniquely identified by a single human-readable field, ideally
name
. This is an extension ofLOCATION_NAME_AS_NATURAL_KEY
(#3977) to become an enforced part of the core data model.So that ...
Location.name
being a unique identifier of a Location, without needing an alternative approach (i.e. natural-key/composite-key) to handle environments whereLOCATION_NAME_AS_NATURAL_KEY
is not set.I know this is done when...
Location.name
is changed tounique=True
"Room 101"
becomes"Atlanta: Building 100: Floor 1: Room 101"
rather than something generic like"Room 101 (2)"
).Optional - Feature groups this request pertains to.
Database Changes
As this is a breaking change to the data model it will need to be done on a major release boundary.
External Dependencies
None.