Symptôme : un job de camping (« Lac des pins | Anton Rimerov ») pointait sur la RÉSIDENCE du client
(428 Rue George, Lasalle = 45.58,-73.73) au lieu du camping. Le pont géocodait l'adresse de compte.
- buildJob : détection camping en PRIORITÉ MAX via le registre camping_registry — signal = sujet (label
explicite, prioritaire) puis ville/adresse de delivery. Garde-fou : le texte doit contenir « camping » OU
un mot-clé de LIEU spécifique (évite les faux positifs de patronyme, ex. « Daniel Dauphinais »). coord_src='camping'.
La branche update fait écraser les coords existantes par le camping (comme delivery). 20 jobs ouverts re-coordonnés.
- camping_dispatch_backfill.sql : corrige les jobs DÉJÀ dispatchés (que le sync ne re-traite plus car le ticket
legacy a quitté le pool ouvert-3301) → 4 Lac des Pins + 2 SandySun. Anton Rimerov/Germaine Thibert → 45.0624,-73.9113 ✓.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Problème : pour un lot de camping, l'adresse du Service Location = souvent la RÉSIDENCE du client, et la
rue interne (ex. « 2 rue Canard, Lac des Pins ») n'est pas dans le RQA → géoloc fausse. Solution data-driven :
table `camping_registry` (mot-clé ville → nom + adresse principale + GPS fixe), coords relevées dans le
legacy delivery. Application : force lat/long du camping sur tous les lots (match ville normalisée), garde
address_line (n° de terrain visible), linked_address = le camping, statut validated.
Appliqué : Lac des Pins 1242 · Dauphinais 134 · SandySun 28 · Frontière 1 (+ Ensoleillé en registre).
Idempotent + ré-applicable. scripts/migration/camping_registry.sql.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
scripts/migration/normalize_service_locations_pass2.sql : pour les SL restées review/unmatched après la
passe 1 (code postal+numéro), rematch par NUMÉRO + VILLE (trigram, normalisation St→Saint) + meilleure rue
par similarité ≥0.30 (rue seule, pas ville-incluse pour éviter le gonflement) → upgrade en validated avec
coords RQA réelles. Récupère les SL au code postal erroné/manquant mais ville valide (ex. Athelstan/Ch Ridge).
Résultat : +264 validated (15 195), unmatched 766→550. GPS sur 17 036/17 111 services (99,6%),
dont 15 195 (89%) rooftop AQ. Les 75 sans GPS = boîtes postales/hors-QC/placeholders/sobriquets camping
(pas de position de service réelle). Idempotent.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
scripts/migration/normalize_service_locations.sql : rattache chaque Service Location à l'adresse
canonique Adresses Québec (table locale rqa_addresses) par CODE POSTAL + NUMÉRO (clé sélective indexée)
+ meilleure rue par similarité désaccentuée (unaccent + pg_trgm). Les 2 tables étant colocalisées dans
la db ERPNext, tout se fait en SQL (~26 s pour 16 345 lignes, pas d'aller-retour applicatif).
Remplit (sans toucher address_line/city/postal_code = origine préservée → table de translation) :
- aq_address_id = rqa_addresses.id (clé de translation locale ; ⚠ id LOCAL, pas l'uuid AQ officiel absent
de la table locale)
- linked_address = adresse canonique conforme (address_full)
- address_validation_status = validated (sim≥0.20) | review (sim<0.20, ex. surnoms de camping) | unmatched
- latitude/longitude raffinées seulement si validated
Résultat : validated 14 931 (87%) · review 1 414 (8%) · unmatched 766 (4,5%) → 16 345 liés (95,5%).
Idempotent (ne traite que les lignes 'pending'). Couvre la tâche « backfill normalisation 17k SL ».
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Three legacy data-quality issues that were leaking into ERPNext on every
import run. Caught while auditing C-LPB4's mis-pinned dispatch job.
1. **Postal code embedded in address_line.** Legacy `gestionclient` had
rows like `2200-3 chemin de la riviere de la guerre J0S1B0` with
the postal code concatenated at the end (and the same code repeated
in the dedicated zip column). Caused 48-char address_line on what
should have been a 39-char address. Now stripped at import: a regex
matches `\\s+<FSA><LDU>\\s*$` (with or without space) and removes
it; the dedicated postal_code field carries the canonical form.
2. **Abbreviations + Cobol-style capitalization.** Legacy stored
`2066 Ch De La 1Re-Concession` instead of the canonical
`2066 Chemin de la 1re-Concession`. ABBREV_MAP expands `Ch` →
`Chemin`, `Av` → `Avenue`, `Bd`/`Boul` → `Boulevard`, `Rte` →
`Route`, `St-` → `Saint-`, `Ste-` → `Sainte-`, `Mtl` → `Montréal`.
Title-casing rule preserves French articles lowercase (`de`, `du`,
`des`, `la`, `le`, `les`, `au`, `aux`, `à`, `et`, `sur`, `en`)
and ordinal markers (`1re`, `2e`, `3e`). 96 SLs in production had
the `1Re-Concession` style; they'll be re-normalized on next
migration run.
3. **`connection_type` left empty even when ONT/CPE devices existed.**
Pre-loads device→delivery mapping at import start; if the legacy
delivery has any device whose category/name/model contains "ont",
"onu", "cpe", "fibre", "gpon", or "ftth", we set
connection_type='Fibre FTTH'. Without devices on file, the field
stays empty (rep fills it later) — we don't guess.
4. **`postal_code` normalized too** — `j0s1b0` → `J0S 1B0` (uppercase
+ canonical space). Was being inserted in lowercase no-space form.
Self-tested on 8 representative cases including the actual broken
records found in production (LOC-15903, LOC-6227, LOC-4 / C-LPB4).
These changes affect only re-imports of locations. Existing data
needs a separate backfill script — a follow-up will cover that
either as a one-shot migration or by running the existing
`reimport_subscriptions.py` after this script.
- EquipmentDetail: collapsible node groups (clients grouped by mesh node)
- Signal strength as RSSI % (0-255 per 802.11-2020) with 10-tone color scale
- Management IP clickable link to device web GUI (/superadmin/)
- Fibre status compact top bar (status + Rx/Tx power when available)
- targo-hub: WAN IP detection across all VLAN interfaces
- targo-hub: full WiFi client count (direct + EasyMesh mesh repeaters)
- targo-hub: /devices/:id/hosts endpoint with client-to-node mapping
- ClientsPage: start empty, load only on search (no auto-load all)
- nginx: dynamic ollama resolver (won't crash if ollama is down)
- Cleanup: remove unused BillingKPIs.vue and TagInput.vue
- New docs and migration scripts
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Found GenieACS MariaDB at 10.100.80.100 (NOT 10.5.14.21 as
configured in ext scripts — that IP was stale/blocked).
Provisioning data:
- 1,713 WiFi entries (858 unique Deco MACs → SSID/password)
- 797 VoIP entries (469 unique RCMG ONT serials → SIP creds)
- WiFi keyed by Deco MAC (403F8C OUI), VoIP by ONT serial
Complete chain verified:
ONT serial (RCMG) → fibre table (OLT/slot/port)
→ device table (delivery_id)
→ delivery (account_id → ERPNext customer)
→ VoIP provisioning (SIP credentials)
→ WiFi provisioning (via linked Deco MAC)
Reconciliation: 2,499 RCMG serials addressable, 2,003 have
full fibre+device chain, 282 have VoIP provisioning attached.
3,185 TPLG serials, 2,935 in both fibre and device tables.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Full data export and cross-reference analysis:
- 7,550 GenieACS devices with IPs, deviceId, tags
- 6,720 legacy devices (raisecom, tplink, onu categories)
- 16,056 fibre table entries (OLT frame/slot/port/ontid, VLANs)
- 8,434 legacy services linked to devices
Key finding: CWMP serial ≠ physical serial. Only 22/7,550 devices
are tagged with their physical serial (RCMG/TPLG). Raisecom MAC
is extractable from CWMP serial suffix. TP-Link CWMP serial = sticker
serial for ONT models.
Matching strategy documented: tag-based, MAC-based, OLT port-based.
Recommends bulk tagging via OLT query as first step.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Add /acs/export endpoint: dumps all provisions, presets, virtual
params, files metadata in one call (insurance policy for migration)
- Add /acs/provisions, /acs/presets, /acs/virtual-parameters, /acs/files
- Shell script export_genieacs.sh for offline full backup
- TR069-TO-TR369-MIGRATION.md: phased migration plan from GenieACS
to Oktopus with parallel run, provision mapping, CPE batching
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Switch Ops data source from Subscription to Service Subscription (source of truth)
- Reimport 39,630 native Subscriptions from Service Subscription data
- Rename 15,302 customers to CUST-{legacy_customer_id} (eliminates hex UUIDs)
- Rename all doctypes to zero-padded 10-digit numeric format:
SINV-0000001234, PE-0000001234, ISS-0000001234, LOC-0000001234,
EQP-0000001234, SUB-0000001234, ASUB-0000001234
- Fix subscription pricing: LPB4 now correctly shows 0$/month
- Update ASUB- prefix detection in useSubscriptionActions.js
- Add reconciliation, reimport, and rename migration scripts
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- InlineField component + useInlineEdit composable for Odoo-style dblclick editing
- Client search by name, account ID, and legacy_customer_id (or_filters)
- SMS/Email notification panel on ContactCard via n8n webhooks
- Ticket reply thread via Communication docs
- All migration scripts (51 files) now tracked
- Client portal and field tech app added to monorepo
- README rewritten with full feature list, migration summary, architecture
- CHANGELOG updated with all recent work
- ROADMAP updated with current completion status
- Removed hardcoded tokens from docs (use $ERP_SERVICE_TOKEN)
- .gitignore updated (docker/, .claude/, exports/, .quasar/)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- 29,178 account_memo → Comment on Customer
- Timestamps converted from unix to datetime
- Author mapped from staff_id → User email
- Visible in Customer page comment section
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- 45 users created with Authentik SSO (no password)
- Roles assigned: System Manager, Support Team, Sales/Accounts
- Service accounts skipped (admin, tech, dev, inventaire, agent)
- Email = Authentik identity link
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
