{% extends 'generic/object.html' %} {% load helpers %} {% block content %}

Cabling application {% if object.cable_ids %} {% comment %} the confirmation is built from `deletable_count` (restrict(user, "delete"), the queryset `CablingApplication.rollback` deletes), never from the view-scoped `cable_count` below: delete and view are independent object permissions, so the badge cannot describe what the button destroys. {% endcomment %}
{% csrf_token %}
{% if deletable_count != cable_count %} Rollback will delete {{ deletable_count }} cable(s). {% endif %} ⬇ Work order (Excel){% endif %}

{% comment %} object-level perms: `cable_count` counts only the cables this viewer may see, like the REST payload — the raw `cable_ids|length` disclosed the size of the whole run. {% endcomment %}

{{ object.source }} — {{ cable_count }} cable(s).

{% for c in cables %}{% endfor %} {% if missing_cables > 0 %} {% comment %} same rule as the job detail: only ids matching NO cable row reach here, so "no longer exist" stays a statement about the database and the count above keeps its invariant — cable_count == rows shown + missing. The job detail has three wordings because its rollback keeps the ids it deleted; this page keeps one, because `CablingApplication.rollback` rewrites `cable_ids` to the cables that survived it. An id left here therefore never names something the plugin deleted (`missing_state` is "outside" for this carrier by construction — see views.CablingApplicationView and visibility.missing_cable_state). {% endcomment %} {% endif %}
CableType
{{ c|linkify }}{{ c.type }}
{{ missing_cables }} cable(s) of the application no longer exist (deleted outside the plugin). A rollback drops from this list what it deletes, so these were not deleted by one.
{% endblock %}