Skip to content

1. Location Management ​

Menu path: Maintenance → Location Management. From backend 2.00.070, locations use full paths with arbitrary depth, such as Campus/Building1/Floor3/Warehouse. Devices, gateways, and templates still reference a location through location_code.

1.1. Fields ​

FieldDescription
codeRequired when adding a location; referenced by devices, gateways, and templates. Migration or path edits preserve the code.
pathFull path including the location name, unique within the current organization. / separates levels.
nameCurrent location name, saved from the last path segment.
remarkFree-text note.
address1, address2, zip_codeAddress and postal code.
phone, managerContact phone and manager.
statusLocation status.
longitude, latitudeGeographic coordinates.
paramsExtension parameters.

The add/edit form combines a parent path and current location name, with a live full-path preview. Fixed area/province/city fields are no longer required. Paths cannot have leading/trailing slashes, empty levels, whitespace, or commas. This table describes data fields; it does not imply every field has a form input.

1.2. Paginated List and Tree ​

The default tab is a paginated list with name, path, and code filters. The path filter matches an exact full path. The list also provides import, export, and selected-record deletion.

The Tree tab shows locations on the left, initially displaying roots with children collapsed. Select any actual location to view its details, descendant count, and paginated device/gateway tabs on the right. The current-location tab matches the selected code; select the current-and-descendants tab for the broader scope described below.

The tree contains only actual location records. If A and A/B/C exist but A/B does not, A/B/C appears as a root and keeps its original path. No intermediate records are invented. Descendant counts and branch deletion use full paths and can therefore include records displayed under another root.

For an empty asset panel, check direct asset bindings and their location_code values.

1.3. Add, Edit, and Move a Branch ​

  1. To create a top-level location, select the top level as parent and enter its code, current name, and other details.
  2. To add a child, use the action in the parent's details or select an existing location in the add form. The parent selector supports search.
  3. Check the preview before saving. Parent Campus/Building1/Floor3 plus name Warehouse produces Campus/Building1/Floor3/Warehouse.
  4. To move a branch, edit its parent; to rename it, edit its current name. The parent selector excludes the location itself and all descendants. Moving into its own descendant is prohibited.

A parent-path change updates all descendant prefixes in one database transaction. A conflict rolls back the entire batch. IDs and codes stay unchanged, so devices and gateways do not need rebinding after a path edit. An existing missing parent path is preserved unless edited, even when the location appears as a tree root.

1.4. Delete Locations ​

ActionLocation records removedDevice/gateway effect
Delete from the paginated listSelected records only; descendants are not recursively removed.Assets remain, and their binding codes are not automatically cleared.
Delete a tree branchThe full path and all descendant location records; confirmation shows the affected count.Assets remain, and their binding codes are not automatically cleared.

Check the affected scope

Visible tree children may not cover the full branch when parent records are missing. Check the affected count before confirming. Assets may retain a code for a deleted location; manually select a valid location for affected devices/gateways when needed.

1.5. Excel Import/Export and Migration ​

Location Excel import/export now uses path instead of the old area, province, and city columns. Export a new template or sample, then enter full paths including names. Preserve IDs when editing existing locations. When a batch changes a parent, unchanged child rows with old paths follow the parent's cascade rather than undoing it.

Migration combines the old area/province/city/name segments, skips empty region values, and falls back to the code for an empty name. Original names and region values are backed up in legacy_hierarchy; the region columns remain but no longer define the business hierarchy. Special characters become percent-encoded text; duplicate paths receive original-ID or additional suffixes. Existing nonempty paths and backups are preserved. All original IDs, codes, and device/gateway binding codes remain unchanged.

Migration does not move object-storage files. Pulling code alone does not upgrade the database. Read the 2.00.070 upgrade notes before deployment.

1.6. Devices, Gateways, and Templates ​

  • Devices and gateways select existing locations through location_code; the interface displays full paths. Path, name, and code are separate fields.
  • Device Configuration Templates can preset location_code for later device creation/import.
  • Device Excel import still uses location_code, unlike location import using path. An unknown location code is cleared for that device, and device import continues.

Maintain locations first, then use their code values in device Excel files.

Current location and descendants (2.00.083) ​

Location details provide separate device/gateway tabs for the current location and for the current location plus descendants. Confirm the selected scope before reading pagination totals; the current page count is not the whole scope total.

For devices, use location_code_subtree on /thinklink/device/find-page-by-fields; for gateways use the same parameter on /thinklink/gateway/find-page. The existing list's location_code still means current location only. Subtrees use complete boundaries of the formal location path, not code-prefix matching. Unknown locations return an empty scope, without falling back to all organization devices.

Location trees and department scopes are different. Business spaces use actual device bindings, not an assumed location subtree. Summaries require all pages, retaining failed, unloaded or stale states. See Micro-application Reads.