app/templates/partials/jobs/status.html

<div class="ajax-block-container">
  <p class='bottom-gutter'>
    {% if job.scheduled_for %}
      {% if job.processing_started %}
        Sent by {{ job.created_by.name }} on {{ job.processing_started|format_datetime_short }}
      {% else %}
        Uploaded by {{ job.created_by.name }} on {{ job.created_at|format_datetime_short }}
      {% endif %}
   {% else %}
      Sent by {{ job.created_by.name }} on {{ job.created_at|format_datetime_short }}
    {% endif %}
  </p>
  {% if job.status == 'sending limits exceeded'%}
    <p class="govuk-error-message">
        Notify cannot send these messages because you have reached your daily limit. You can only send {{ current_service.message_limit|format_thousands }} messages per day.
    </p>
    <p class="govuk-error-message govuk-!-margin-bottom-6">
        Upload this spreadsheet again tomorrow or <a class="govuk-link" href="https://www.notifications.service.gov.uk/support">contact the U.S. Notify team</a> to raise the limit.
    </p>
    {% endif %}
</div>
Make sure partials always have a wrapping `<div>` The diffDOM Javascript sometimes throws an error if it can’t calculate a diff between the original content of the page and the updated HTML delivered via AJAX. The problem seems to be when there’s not one, consistent top-level element for it to base its calculations on. This commit: - makes sure that all AJAX-delivered partials have a wrapping `<div>` - that this `<div>` has a consistent class name to make it clear why it’s there 2016-09-01 11:06:52 +01:00			`<div class="ajax-block-container">`
Revert "Merge pull request #1336 from alphagov/revert-show-notifications" This reverts commit 7e354ff341172041d6141b50833af6262308fcb4, reversing changes made to 6f3bcff32fbfc78b4df0558d08605a260786112f. 2017-06-24 17:12:45 +01:00			`<p class='bottom-gutter'>`
If possible, show sent not uploaded time for jobs If you’re looking back at a job that was scheduled and has now been sent it’s more useful and consistent to know what time it went out. The time it was uploaded at is a bit arbitrary once it’s sent. The only time the uploaded time is relevant is when the job is still waiting to be sent. Slightly fiddlier than it sounds because we never want to show ‘uploaded by’ for a job that hasn’t been scheduled because it almost immediately changes to ‘sent by’. This flickering of the UI is undesirable. 2016-10-12 09:23:59 +01:00			`{% if job.scheduled_for %}`
			`{% if job.processing_started %}`
			`Sent by {{ job.created_by.name }} on {{ job.processing_started\|format_datetime_short }}`
			`{% else %}`
			`Uploaded by {{ job.created_by.name }} on {{ job.created_at\|format_datetime_short }}`
			`{% endif %}`
Show status when job has exceeded the daily sending limit If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created. 2021-07-05 14:13:20 +01:00			`{% else %}`
If possible, show sent not uploaded time for jobs If you’re looking back at a job that was scheduled and has now been sent it’s more useful and consistent to know what time it went out. The time it was uploaded at is a bit arbitrary once it’s sent. The only time the uploaded time is relevant is when the job is still waiting to be sent. Slightly fiddlier than it sounds because we never want to show ‘uploaded by’ for a job that hasn’t been scheduled because it almost immediately changes to ‘sent by’. This flickering of the UI is undesirable. 2016-10-12 09:23:59 +01:00			`Sent by {{ job.created_by.name }} on {{ job.created_at\|format_datetime_short }}`
			`{% endif %}`
Make a macro for the AJAX update module This is less repetitive than typing out the HTML with all its attributes every time. It also lets us wrap up the idea of ‘finished’ as a parameter, so the AJAX code will only be initiated when it’s needed, eg if a job is still processing. 2016-06-28 09:21:46 +01:00			`</p>`
Show status when job has exceeded the daily sending limit If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created. 2021-07-05 14:13:20 +01:00			`{% if job.status == 'sending limits exceeded'%}`
Update content 2021-07-14 09:54:28 +01:00			`<p class="govuk-error-message">`
			`Notify cannot send these messages because you have reached your daily limit. You can only send {{ current_service.message_limit\|format_thousands }} messages per day.`
			`</p>`
			`<p class="govuk-error-message govuk-!-margin-bottom-6">`
us → u.s. 2022-12-06 11:03:47 -05:00			`Upload this spreadsheet again tomorrow or <a class="govuk-link" href="https://www.notifications.service.gov.uk/support">contact the U.S. Notify team</a> to raise the limit.`
Show status when job has exceeded the daily sending limit If a job exceeds the daily sending limit, show that on the job page. The job is only created if the sending limit has been reached when the delivery app is processing the job, usually this error is caught at the time the CSV is uploaded and the job is not created. 2021-07-05 14:13:20 +01:00			`</p>`
			`{% endif %}`
Make a macro for the AJAX update module This is less repetitive than typing out the HTML with all its attributes every time. It also lets us wrap up the idea of ‘finished’ as a parameter, so the AJAX code will only be initiated when it’s needed, eg if a job is still processing. 2016-06-28 09:21:46 +01:00			`</div>`