Cambiar la IP de un equipo desde su ficha (readdress)

User value

Un equipo detectado por Auto-Provision (un router, un switch, un punto de acceso…) vive a la vez en tres sitios: su ficha (DeviceProfile), su sonda de monitorización en Observatory (MonitoringTarget) y, si está colocado en un rack, su tarjeta en el Rack Editor (Device). Si ese equipo cambiaba de IP — un router reconfigurado, un cambio de VLAN de gestión — hasta ahora la única forma de reflejarlo era borrar la ficha entera y dejar que el descubrimiento automático la encontrara de nuevo desde cero.

Task #313. Desde v1.132.5 la IP se edita directamente: en “Edit Card” → Identity (campo “IP Address”, fuera del bloqueo manual del resto de la ficha) o desde la ficha del target en Observatory. El cambio se propaga solo a los tres sitios. Si la IP nueva ya la usa otro equipo, se avisa y no se guarda nada — ni la IP ni el resto de campos que se estuvieran editando a la vez.

Límite honesto (declarado en el propio CHANGELOG): no cubre el auto-discovery (provision_stages.py) ni la deduplicación por MAC — eso queda para la task #314, que reutilizará este mismo servicio.

Cómo usarla

1. Abrir la ficha del equipo (Edit Card) desde cualquier listado que la ofrezca (Wireless, UPS, Digital Signage, Devices…).
2. En la sección Identity, editar el campo “IP Address”.
3. Guardar. La IP viaja primero y por separado del resto de campos (PATCH /auto-provision/profiles/{id}/ip): si choca con otro equipo, el resto de la ficha no llega a tocarse.
4. Alternativa: editar la IP directamente desde la ficha del target en Observatory (PUT /api/monitoring/targets/{id}) — si ese target tiene un perfil de Auto-Provision vinculado, el cambio se delega igualmente en el mismo servicio.

Cambio de IP detectado por un re-escaneo (B-27, 25-09-2026)

El caso de arriba es el cambio a mano. El automático — un re-escaneo que ve la MAC de un equipo conocido en otra IP — quedaba pendiente desde la task #314 (14-09-2026), que lo aplicaba solo. Decisión de Edu del 25-09-2026 que sustituye esa: el cambio ya no se aplica automáticamente, se deja pendiente de confirmación.

• El discovery llama a network/services/readdress.py::propose_ip_change(profile, new_ip): guarda la IP nueva en DeviceProfile.pending_ip_address (sin tocar ip_address) y dej a constancia en el registro del sistema (SystemLog, categoría NETWORK).
• La página Devices ofrece dos botones sobre la ficha con aviso pendiente: Apply new IP (POST /auto-provision/profiles/{id}/pending-ip/apply) reutiliza el mismo change_profile_ip de siempre — mismo camino, mismos efectos en Observatory y rack. Dismiss (POST /auto-provision/profiles/{id}/pending-ip/dismiss) guarda la IP en dismissed_ip_address y ya no se vuelve a proponer ni genera una segunda ficha con esa MAC.
• Si una pasada posterior vuelve a ver el equipo en su IP de siempre, el aviso pendiente se limpia solo (clear_stale_ip_change).
• Si la MAC aparece en una IP que ya tiene la ficha de OTRO equipo, no se propone ningún cambio (no podría aplicarse sin colisión), pero queda registrado (log_ip_taken_by_other_profile).
• Migración aditiva network/0067_deviceprofile_pending_ip.py — dos columnas nulas en device_profiles, que ya tenía su política RLS por organización (sin política nueva).

Por qué cambió: la decisión de la task #314 aplicaba el cambio en cuanto el discovery reconocía la MAC, sin que nadie lo viera. La nueva decisión prioriza que un cambio de IP silencioso puede ser tanto un router reconfigurado como una incidencia de red que conviene que un humano confirme.

Implementación

Único punto de coherencia (Regla 2 del proyecto): network/services/readdress.py::change_profile_ip(profile, new_ip) sigue siendo el único código que escribe ip_address. Lo llaman:

• PATCH /api/network/auto-provision/profiles/{id}/ip (network/api/profiles.py::change_profile_ip_endpoint) — cambio a mano.
• PUT /api/monitoring/targets/{id} (monitoring/api/targets.py::update_target) — si la IP cambia y el target tiene un [[entity—network—model—deviceprofile|DeviceProfile]] vinculado, delega en change_profile_ip.
• POST /auto-provision/profiles/{id}/pending-ip/apply (apply_pending_ip_endpoint, B-27) — confirma la IP pendiente con el mismo servicio.

Dentro de una transacción, el servicio valida formato, rechaza duplicados, actualiza profile.ip_address (y limpia pending_ip_address si había una pendiente), arrastra el MonitoringTarget vinculado y cualquier otro que aún tuviera la IP vieja, reescribe management_config del Device de rack si existe, y notifica al Agente Local. Devuelve {"changed", "old_ip", "new_ip", "target_updated", "device_updated"}.

El camino de propuesta pendiente vive aparte, en el mismo fichero: propose_ip_change, clear_stale_ip_change, log_ip_taken_by_other_profile y dismiss_pending_ip_change — todos escriben en SystemLog/log_action, ninguno toca ip_address directamente.

En el frontend, static/js/network/device_card_editor.js trata ip_address como campo especial: no viaja dentro de identity (el PUT normal de la ficha), no se marca “a mano” y no admite “Auto”; se guarda antes y por separado, así que un conflicto de IP no bloquea el resto de cambios de la ficha.

Commits relacionados

• 3fd3806229ae92fffd665033cc8d0caf286d3d2e (2026-09-14, PR #535) — feat(network): la IP de un equipo se cambia desde su ficha con un servicio único (perfil + Observatory + rack) · v1.132.5 · task #313.
• 11d687c404a1755c9dc0c86a30a9bdb87914efd3 (2026-09-25, PR #608, v1.160.0) — B-27/T26: el re-escaneo deja el cambio de IP pendiente de confirmación (Apply/Dismiss) en vez de aplicarlo solo; migración network/0067.

Véase también

• [[entity—network—model—deviceprofile]]
• [[entity—monitoring—model—monitoringtarget]]
• [[entity—network—endpoint—profile-config]]
• [[entity—monitoring—endpoint—enable-monitoring-profile]]
• [[entity—monitoring—service—target-lifecycle]]
• [[feature—network—autoprovision-refresh-dispositivo]]
• [[entity—network—model—devicetrashentry]]
• [[entity—terminal—service—terminal-hosts]]