{% load tz %}{% comment %} One step of the composer, the stepper that navigates between them, and the summary panel beside them (HANDOFF §3, Broadcasts). The step to render is chosen in Python (apps/broadcasts/views.py::_requested_step) against a fixed tuple, so nothing here builds a template name out of a request parameter. The four includes are spelled out for the same reason. {% endcomment %} {% comment %} The progress rail. `reached` — the furthest step this broadcast has got to — has always been in the context and was never rendered, so the rail showed where you are but not how far along. A step before `reached` is done and shows a tick; the connector between two done steps fills in. `step_labels` rather than the raw names: the fourth step is stored as "content" and read as "Message". {% endcomment %}
    {% for row in step_rows %} {% if not forloop.first %}{% endif %}
  1. {% endfor %}
{% if error %} {% endif %} {% if step == "channel" %}{% include "broadcasts/_step_channel.html" %} {% elif step == "audience" %}{% include "broadcasts/_step_audience.html" %} {% elif step == "content" %}{% include "broadcasts/_step_content.html" %} {% elif step == "schedule" %}{% include "broadcasts/_step_schedule.html" %} {% else %}{% include "broadcasts/_step_review.html" %} {% endif %}
{% comment %} The summary panel (HANDOFF §3, Broadcasts): what has been decided so far, and the checks that have to hold before anything is sent. Re-rendered with every step, so it always matches the row. The checks are a reading aid — every one is enforced again, server-side, by schedule_broadcast at the moment of sending — and each has a word beside its mark, never colour alone. {% endcomment %}