Skip to content
Vinxi/Kernel THE BOOK OF RECORD

SmartInventory Web UI — Live Entity Grounding (real data)

Captured 2026-06-17 against the live demo (networkaccess.st.leptonsoftware.com, v8.16.4.0) once the host came back up and a data-bearing workspace was loaded. This is the first capture grounded in real network data (the earlier sessions had an empty default workspace). READ-ONLY: nothing was created/edited/saved.

How the live data was reached (reusable playbook)

  1. Login (admin/Demo@2023) → /Products/main.
  2. The default workspace has no project/layer mapping (getLayerMapping() → []), so nothing renders. Open a saved workspace: si.OpenWorkspace(<id>) (workspace manager = si.getWorkSpaces(); IDs seen ~200–202, names like “SIP VIEW”, “bishal_workspace”). Workspace 201 restores an extent over Agra, Uttar Pradesh (~27.177°N, 78.012°E) and sets a server-side region filter (regionFilter=[region_id] in (58)).
  3. Map rendering = MapServer WMS at :8091/cgi-bin/mapserv.exe, mapfile F:/Application/SmartInventory_Product/MapFiles/NetworkEntitiesNoLabel.map, EPSG:4326, layers requested by map_abbr (REG/PRO for region/province, plus per-entity layers). Layer visibility is toggled per network_status: four checkboxes per layer — chk_netP/A/D/L_<layerId> (Planned / As-built[Implementation] / Dormant[Operation] / L) via si.handleChClick().
  4. Identify: POST /Products/Main/GetNearByEntities {latitude, longitude, bufferInMtrs} → returns an HTML panel of nearby entities, each as si.showElementInfo(systemId, type, geomType, networkCode, status, networkCode, WKT). (Region context must match the data, else empty.)
  5. Open one entity → si.showElementInfo(...) fires POST /Products/main/GetEntityInfo {systemId, entityType, geomType} (JSON) + GetEntityInfoToolbar + GetLayerDetail {layerName}.

The entity attribute model is confirmed registry-driven (live)

GetLayerDetail {layerName:"Trench"} returned the live layer_details row — matching the DB analysis exactly:

layer_id=16, layer_abbr=TRH, layer_table=att_details_trench, layer_view=vw_att_details_trench,
layer_form_url=/AddTrench, save_entity_url=/SaveTrench, template_form_url=ItemTemplate/TrenchTemplate,
network_id_type=A (automatic codification), network_code_seperator=-, is_template_required=true,
is_vendor_spec_required=true, is_osp_layer=true, is_mobile_layer=true, minzoomlevel=12, geom_type=Line ...

So the client fetches the registry row and uses layer_form_url/save_entity_url/layer_table to drive the form and persistence — the “config-not-code” mechanism, observed live end-to-end.

A real entity, fully grounded: Trench AGR-TRE000001 (system_id 207352)

GetEntityInfo returns the attribute list as JSON: {db_column_name, display_column_name, old_value, updated_value, is_updated, DRAFT_MESSAGE} per field — i.e. it carries the draft/approval delta (old vs updated value) inline. 100 attributes on this one Trench. Selected live values (grounds att_details_trench):

db_columnvaluedb_columnvalue
network_idAGR-TRE000001trench_typeHDD
trench_nameAGR-TRE000001trench_width0.30
parent_codeAGRtrench_height0.30
parent_typeDivisiontrench_length94.66
statusApprovedno_of_ducts0
specificationGenericownership_typeOwn
vendor_nameGenericitem_codeItem/GN01
categoryTrenchbom_sub_categoryProposed
trench_serving_typeDistribution Serving typeutilization0
region_name / a_region / b_regionUttar Pradesha_cityAgra
country_nameIndiaprovince_id195
area_idAGR-ARA000002source_ref_typeWEB
b_longitude78.011478 27.176923created_by_id5

Other fields present (mostly empty in this record) reveal the full domain surface of the Trench entity: the A/B endpoint model (a_location/b_location, a_entity_type/b_entity_type, a_region/b_region, origin_from, origin_ref_id/code/type), POD linkage (primary_pod_network_id, secondary_pod_network_id, primary_pod_name, secondary_pod_name, served_by_ring), project/work-order linkage (project_code/name, workorder_id/name/code, planning_id/name, jc_id, requested_by, request_approved_by, request_ref_id), hierarchy/geography (dsa_id, subarea_id, area_id, hierarchy_type, pin_code, mcgm_ward), costing/BOM (bom_sub_category, subcategory1/2, third_party_vendor_id/name, purpose_id/name/code), lifecycle/audit (status, status_remark, status_updated_by/on, ticket_network_status, is_used, is_visible_on_map, modified_by/on), and strata_type, actual_no_of_ducts, ne_id, design_id, prms_id.

This is the live entity attribute view. The editable form is the route /AddTrench (opens over the map after a geometry is drawn; the standalone GET returns the full map shell, confirming the form is a draw-then-fill overlay), saving via /SaveTrench. Dynamic/EAV custom fields are appended via the dynamic_controls-driven section (per the screen catalog / _AdditionalAttributesForm.cshtml).

Screenshots

references/ui-exploration/shots/detail/: ws-01.png (workspace manager list), ws-open-201.png + live-net-01.png (Agra data extent at building zoom), ident-01-toolon.png (Information/identify tool active). Raw payloads: entityinfo_trench.html (100-field JSON), layerdetail_trench.json (the live layer_details row), entity_samples.json.

Live visible captures (2026-06-18) — the Agra FTTH network

Once a data-bearing workspace was open, the full network rendered. Inventory at the Agra POD area (via GetNearByEntities, ~900 m) = 459 entities: Cable 79, Manhole 50, SpliceClosure 44, POD 31, FMS 29, BDB 19, Trench 17, Duct 16, ONT 15, Structure 14, Equipment 14, HTB 13, Rack 11, Building 11, Splitter 10, FDB 8, plus ADB/CDB/Coupler/Tower/Fault/etc. (agra_entities.json). Network codes are AGR-*; an OLT exists (Equipment 6620 = AGR-BLD000008_001-POD00001-OLT…). Screenshots in references/ui-exploration/shots/detail/:

  • LIVE-splice-01-main.png — the live network on the map (splice-closure icons, distribution boxes, cables drawn as lines) at building zoom in Agra.
  • LIVE-splice-10-window.png — the Splicing tool open (splicing.initiateSplicing → POST /Products/Splicing/Index): a panel with tabs “Cable to Equipment” and “CPE to Customer”, a “Filter cables on device only” toggle, Equipment / Left Cable / Right Cable selectors, a Selected/ISP-Equipment/Virtual radio, and Splice/Cancel — over a yellow buffer at the splice point. This is the real splice editor entry (zoom ≥19 gated).
  • LIVE-olt-10-equipment.png / LIVE-olt-20-portdiagram.png — the “Cable to Equipment” (OLT/equipment patching) tab opened at the POD building AGR-BLD000008 with the Equipment selector populated by real ISP equipment and their port counts: FMS …PO.xxx (22 ports), FDC …FDC01 (12), FAT …FAT0001 (12), HTB …ATB001 (12), ONT …OT0000001 (2:4) — all (P)/(ISP). Selecting the FMS populated the Cable selector with a real 24-fiber cable FC_AGR_OB_TE_AR_ARON_LM001_R1-(24F). ~32 port elements rendered in the panel.

These confirm, against live data, the splice model: equipment (with N ports) ↔ cable (with N fibers/cores), spliced via connection_info, exactly as the source + DB analysis described.

Status of the three target screens

  • Entity attribute form — ✅ fully grounded in live data (100-field Trench payload + live layer_details config + draft/approval delta + form/save routes).
  • Splicing tool — ✅ opened live and captured (the Cable-to-Equipment / CPE-to-Customer splice editor with real equipment+cable selectors and port/fiber counts). ⚠️ The final fully-wired jsPlumb fiber-core-to-port canvas (the visual splice matrix) did not render under headless automation: the “Splice”-to-load-canvas step is gated by the Chosen-widget selection + map-interaction validation, and I stopped rather than risk a mutation. Zero save/delete endpoints were ever called — nothing was modified. The canvas’s structure (ports/cores/connectors, Splicing/SplicingWindow→getConnectionInfo) is documented from source in SmartInventory_WebUI_Splicing_and_Entity_Forms.md.
  • OLT patching — ✅ confirmed it is the splice tool’s “Cable to Equipment” mode; captured live with the real OLT-site equipment list + port counts. Same jsPlumb-canvas caveat as above.