Allow admins the ability to manually record a bounce message to a user account

[MattK1234]

The automated script catches most of them, but sometimes a bounce / failure message in response to a WDTK notification email (usually a track) does still get through to the team@ mailbox.

At the moment these are manually recorded by developers using the console. Could admins be given the ability to record the bounce message via the Alaveteli admin interface?

Not a major issue, we don't get loads, but if they're not acted on the bounce messages will keep coming through to the WDTK inbox.

[RichardTaylor]

+1 I'd have used this today, and it would have helped stop a series of

Undeliverable: Your WhatDoTheyKnow email alert

messages to the support inbox.

Would the admin button say "pause tracks/alerts"?

Would we want user-facing pause / un-pause tracks/alerts buttons too?

[garethrees]

We already have User#record_bounce so through the console:

user = User.find(USER_ID)
user.record_bounce(<<~MSG)
foo
MSG

Could look at adding a field to the edit form, but we'd need a callback to update email_bounced_at at the same time. We also ensure the string is UTF8.

Alternative is something like Admin::Users::RecordBounceController with edit and update actions.

[garethrees]

Would the admin button say "pause tracks/alerts"?

This issue is about being able to manually populate User#email_bounce_message, so I'd title the button "Record Bounce". Other code checks for the presence of a bounce message in relation to tracks

Would we want user-facing pause / un-pause tracks/alerts buttons too?

That already exists on the user's "wall" page.

For now, we'll just add the button to the main button toolbar, but we ought to think about tidying that up at some point in the future.

[RichardTaylor]

Would the admin button say "pause tracks/alerts"?

I'd title the button "Record Bounce".

I would have been thinking about making it as clear as possible to new admins what the button does, and when to use it. Maybe "Record bounce (stops emails, prevents bounce messages)", but that's getting long.

As for admins reverting a recorded bounce, a "clear bounce" button appears on admin pages already where a bounce has been recorded:

[garethrees]

I would have been thinking about making it as clear as possible to new admins what the button does, and when to use it

I'd put detailed explanatory text on the form that the button links to. Could also see if a tooltip works on a button element.

a "clear bounce" button appears on admin pages already where a bounce has been recorded

Yeah I did think about this – and mocked it up – but it felt like mixing actions with information display is a little confusing. It's not so bad when a bounce has been recorded because that's an "unusual" state so it's fine for it to look "unusual".

Using a link makes it more difficult to differentiate between a user with a bounce and one without.

A more unobtrusive button might work though, in that the differentiation between a user with a bounce and one without is quite clear.