Once you have installed this extension, your locations will be enriched with those fields:
Roomcan have a
Buildingas parent, but also a
Siteor even another
Address ? allow to say for a child location if the
Country should be automatically copied from the parent location, thus avoiding duplicate entries and incoherence if parent address is modified later.
copied from parent if defined, then any entry you do in
Countrywill be overwritten by values from the parent.
A new tab display the direct sub-locations of the current location
When searching for Physical Devices (or Contacts) located on a given Location, iTop will now return all Physical Devices (or Contacts) located on that Location or on any child location below in the hierarchy.
As you can define sub-sites under a site belonging to different organizations, you can segment your CIs, putting them on a Location within their silo and still be able to see all CIs from all organizations located on the parent site or any sub-locations down the hierarchy.
|2019-05-16||1.0.1||Fix PHP warning “missing 3rd parameter GetAttributeFlags”|
|2019-02-27||1.0.0||First official version|
presentationis fully redefined by this extension, it can conflict with other extensions which would modify as well the Location class.
If a location type is changed, there is no control that its children locations types are still aligned with the types order.
Example if you change a 'Site' location having 'Buildings' sub_locations under it, into a 'Room' type of Location, then the 'Buildings' would still remain under the 'Room' also it's not logical. If you modify one of those 'Building' and remove the 'Room' parent, once submitted, it won't be possible to put it back.
Location class on your iTop, not customized by other extensions.
Use the Standard installation process for this extension.
Once the new module has been installed, edit the configuration file config-itop.php and look for the following new section:
'combodo-location-hierarchy' => array ( 'separator' => ' - ', ),
This is how a list of locations will look like
The details of a Location with its sub-locations:
Editing the parent location, limited to those of a higher Type level:
Searching for PhysicalDevices located on a Location or any location below that one:
Question: I need different values for Location types, can I change them?
Answer: Yes, you can do this through an extension which would modify the dictionary entries
<dictionaries> <dictionary id="EN US" _delta="define_if_not_exist"> <entries> <entry id="Class:Location/Attribute:type/Value:1" _delta="force"><![CDATA[Campus]]></entry> <entry id="Class:Location/Attribute:type/Value:2" _delta="force"><![CDATA[Site]]></entry> <entry id="Class:Location/Attribute:type/Value:3" _delta="force"><![CDATA[Tower]]></entry> <entry id="Class:Location/Attribute:type/Value:4" _delta="force"><![CDATA[Floor]]></entry> <entry id="Class:Location/Attribute:type/Value:5" _delta="force"><![CDATA[Room]]></entry> <...>
Question: I would like less (or more) than 5 level of Locations, how can I do?
Answer: Yes, you can do this through an extension which would modify the possible values for
<itop_design> <classes> <class id="Location"> <fields> <field id="type" _delta="must_exist"> <values _delta="redefine"> <value id="1">1</value> <value id="2">2</value> <value id="3">3</value> <value id="4">4</value> </values> </field> <...>
If you add level don't forget to add also dictionary entries for the newly created level. Use numeric values in decreasing order (parent location having a lower value than its sub-locations) or you will break the proposed parent logic.
Question: Can I prevent location of a same type to be proposed as parent?
Answer: Yes, you can do this through an extension which would modify the parent filter
<itop_design> <classes> <class id="Location"> <fields> <field id="parent_id" _delta="must_exist"> <filter _delta="redefine"> <![CDATA[SELECT Location WHERE (type < :this->type)]]> </filter> </field> <...>
Question: I have found a floor location which is the parent of a site location, how is it possible?
Answer: When you modify the
type of a location, it does not check nor modify the types of the locations above and under the one you modify, so it is possible to break the hierarchy logic this way. You can build an audit rule to check such unexpected situation:
SELECT Location AS p JOIN Location AS c ON c.parent_id BELOW p.id WHERE p.type > c.type
Question: I want that the fullname of Location uses the reverse order of the hierarchy?
Answer: Check the Location method
UpdateFromParent and change this line:
to replace by this one: