OLT and ONU Integration — Database, Sync, UI, Permissions, and Documentation

[lupael]

Create olts and onus tables (use oltname, ip_address; no secret field)

Description
Create dedicated database tables for OLTs and ONUs. Follow multi‑tenancy fields sid, mgid, gid, operator_id. Do not include any secret column. Store credentials as plain strings per current instruction.

Tasks

• Create migration for olts table with columns:
  • id (PK)
  • oltname (string) — human name for OLT
  • ip_address (string) — IPv4/IPv6 address
  • type (string, nullable) — vendor/model
  • description (text, nullable)
  • ssh_port (unsigned integer, default 22, nullable)
  • telnet_port (unsigned integer, default 23, nullable)
  • snmp_community (string, nullable)
  • username (string, nullable)
  • password (string, nullable)
  • enablepasswordrequired (boolean, default false)
  • enable_password (string, nullable)
  • status (string, default inactive)
  • sid, mgid, gid, operator_id (unsigned big integers, nullable)
  • createdat, updatedat
• Create migration for onus table with columns:
  • id (PK)
  • olt_id (FK → olts.id)
  • onu_identifier (string) — unique per OLT (serial/ID)
  • olt_port (string, nullable) — slot/port info
  • status (string, nullable)
  • signal_level (string/decimal, nullable)
  • lastsyncedat (timestamp, nullable)
  • sid, mgid, gid, operator_id (unsigned big integers, nullable)
  • createdat, updatedat
• Add unique index on (oltid, onuidentifier).
• Add indexes on tenancy fields (mgid, gid, operatorid) and on ipaddress and lastsyncedat.
• Create Eloquent models Olt and Onu with $connection, $fillable, and relationships:
  • Olt->onus() (hasMany)
  • Onu->olt() (belongsTo)
• Add migration tests to verify schema and indexes.

Acceptance Criteria

• Migrations run without errors.
• onus enforces uniqueness per OLT.
• Models exist and basic relationships work in tests.

Labels: database, backend, migration

---

Implement OLT add/edit form and server-side connection validation (no secret)

Description
Implement UI and server-side logic for adding/editing OLTs. The form must collect oltname, ipaddress, sshport, telnetport, snmpcommunity, username, password, enablepasswordrequired, enable_password, and operator selection. On submit the system must attempt connection checks and reject invalid data.

Tasks

• Create frontend form with fields:
  • oltname, ip_address, type, description
  • sshport, telnetport, snmp_community
  • username, password
  • enablepasswordrequired (checkbox), enable_password (conditional)
  • Operator selection dropdown (same logic as router operator selection)
• Server-side Request validation rules:
  • oltname: required|string|max:255
  • ip_address: required|ip
  • sshport, telnetport: nullable|integer|min:1|max:65535
  • snmp_community: nullable|string|max:255
  • username, password, enable_password: nullable|string|max:255
  • tenancy fields set from authenticated user context (do not accept arbitrary values from request)
• Implement connection checks before saving:
  • SNMP: if snmp_community provided, perform SNMP GET (e.g., sysDescr) to validate community.
  • SSH: if username and password provided, attempt SSH login to ipaddress:sshport.
  • Telnet: if telnet_port provided, attempt socket/telnet connect and login if credentials provided.
  • Enable mode: if enablepasswordrequired is true, attempt to enter enable/privileged mode using enable_password (if applicable).
• If any required connection check fails, return validation errors listing which checks failed and why; do not save the OLT.
• On success, save OLT record with sid, mgid, gid, operator_id set from authenticated user context.
• Add unit/integration tests that simulate connection success/failure (use mocks for network calls).

Acceptance Criteria

• Form validates inputs and shows clear errors.
• Connection checks run and block save on failure.
• Successful connection leads to saved OLT and redirect to OLT detail page.

Labels: backend, frontend, validation

---

Apply router permission checks to OLT management and ONU visibility

Description
Reuse existing router permission logic (router add/edit/view) to control who can add/edit/view OLTs. Enforce tenancy filters in all queries.

Tasks

• Ensure only users with router add/edit/view permissions can add/edit/view OLTs.
• Group Admin behavior:
  • Can add OLTs.
  • Can view all ONUs within their mgid/gid.
• Operator behavior:
  • Can view ONUs only for their operator_id.
• Apply tenancy filters (sid, mgid, gid, operator_id) in controllers and repository queries.
• Add authorization tests for each role and action.

Acceptance Criteria

• Unauthorized users receive 403 on OLT management routes.
• Group Admin and Operator views are filtered correctly.

Labels: auth, permissions, backend

---

Implement scheduled sync to collect OLT health and ONU data

Description
Implement scheduled Artisan commands to poll OLTs using the provided connection details and upsert ONU records into onus. Ensure idempotency, logging, and lastsyncedat updates.

Tasks

• Add Artisan commands and register in app/Console/Kernel.php:
  • sync:olts — iterate enabled OLTs and trigger per-OLT sync
  • sync:onus — optional separate command for ONU-only sync
• For each OLT:
  • Use ipaddress, sshport, telnetport, snmpcommunity, username, password, enable_password to connect.
  • Prefer SNMP for bulk ONU listing if supported; fallback to SSH/Telnet parsing if required.
  • Parse ONU list and metrics (identifier, port, signal, status).
  • Upsert into onus using (oltid, onuidentifier) as unique key.
  • Update lastsyncedat, status, signallevel, oltport.
• Ensure idempotency: repeated runs do not create duplicates.
• Add structured logging (success/failure per OLT), retry/backoff, and failure counters.
• Make polling interval configurable (global default and per-operator override).
• Add monitoring hooks or admin view for repeated failures.
• Add unit/integration tests with mocked device responses.

Acceptance Criteria

• Sync commands run via scheduler and update onus.
• No duplicate ONUs created.
• Failures are logged and surfaced.

Labels: backend, scheduler, integration

---

Match PPPoE customers to ONUs and show ONU on customer detail

Description
Implement matching logic to associate PPPoE customers/sessions with ONUs and display matched ONU info on the PPPoE customer detail page.

Tasks

• Define matching keys based on OLT telemetry (examples: onuidentifier, oltport, interface, mac).
• Implement a matching job that runs after each ONU sync and on PPP session events.
• Persist mapping:
  • Option A (preferred): add nullable onuid to pppoecustomers and update on match.
  • Option B: create pppoecustomeronu mapping table with pppoecustomerid, onuid, sid, mgid, gid, operatorid.
• Update PPPoE customer detail view to show:
  • OLT name (from olts), ONU identifier, signallevel, status, lastsynced_at.
• Provide fallback UI when no match exists (message + troubleshooting link).
• Add tests for matching logic and UI.

Acceptance Criteria

• Matched ONU appears on PPPoE customer detail page.
• Matching job handles edge cases and logs mismatches.

Labels: backend, frontend, feature

---

Security, audit logging, and documentation for OLT/ONU integration (no secret)

Description
Implement audit logging and document the new OLT/ONU features. Note: per current instruction, credentials are stored without encryption and secret is not used.

Tasks

• Add audit logs for OLT create/edit/delete and manual sync actions (who, when, what).
• Sanitize raw SNMP/SSH/Telnet outputs before storing or showing in UI.
• Document credential handling policy (explicitly note no encryption per current requirement) and rotation guidance.
• Update onboarding docs (in the same style as ONBOARDING_GUIDE.md) to include:
  • How to add OLTs (fields required: oltname, ipaddress, sshport, telnetport, snmpcommunity, username, password, enablepasswordrequired, enable_password)
  • Connection validation behavior on submit
  • How sync works and how PPPoE matching is performed
• Provide ERD text snippet showing olts ← onus (via oltid) and tenancy fields sid, mgid, gid, operatorid.
• Add developer notes: where to implement code, which existing utilities to reuse, and test guidance.

Acceptance Criteria

• Audit logs capture required actions.
• Documentation updated and reviewed.
• ERD and developer notes available in repo docs.

Labels: docs, security, audit