Send Test Text and Send Test Email buttons missing until after save

[Benjamin Kalish]

On the patron edit screen the "Send Test Text" button does not appear until after a "Default SMS/Text Number" and a "Default SMS Carrier" have been entered and the record saved.

Similarly, the "Send Test Email" button does not appear until after an email address has been entered and the record saved.

There is also the question of whether the button should be hidden or merely disabled until the number and carrier is entered, but the most important thing from a usability perspective is that one should not have to save the record just to gain this functionality. The buttons should be usable as soon as the information is entered.

This behavior has been observed in Evergreen 3-7-3.

[Terran McCanna (tmccanna)]

Can you please describe a use case? In my experience, I've only ever sent tests when a patron says they are not receiving their notices, so I am always testing based on previously saved info.

[Jason Boyer (jboyer)]

I do think it would be good to display the buttons but visibly disable them rather than hide them.

I'm not as fond of the idea of just firing away with whatever data may be entered on screen. The way the test works is to fire an action trigger event (which is how all of these things work behind the scenes) and that doesn't accept emails for users, only their user ids. Since it's a test of what would actually happen in an A/T event for that user it should use the A/T infrastructure to do it.

[Benjamin Kalish (bkalish)]

The use case is simple: you have entered contact information and want to make sure it is correct. This is particularly import with the SMS carrier which may not be obvious–often you will need to try several carriers.

[Benjamin Kalish (bkalish)]

@jboyer, you say you aren't fond of "firing away with whatever data may be entered on screen", but what data would you besides what has been entered on the screen? And isn't this exactly what happens when you press the button? If it is using any information other than what is displayed on the screen I think that would be very counterintuitive.

[Jason Boyer (jboyer)]

I explained (perhaps too briefly) what happens when you push the button. An action tigger event is generated and immediately run. Because almost all a/t events are run by a cron job with no ui, there's no way to say "send an email to <email address hidden>," it's more like "send an email to user 123" so the a/t runner looks up user 123 and sends the message to their saved email address.

One possible approach to meet in the middle would be to have these buttons save the data first if needed and having the buttons disabled only when their fields are empty. That should simplify things for front desk staff without a bunch of big changes behind the scenes.

[Terran McCanna (tmccanna)]

Saving the data when the button is pushed would be problematic for new accounts that aren't actually ready to be saved yet, though.

I think this request would require creating a new feature that doesn't use an action trigger at all.

[Benjamin Kalish (bkalish)]

@tmccanna, I never create new accounts and hadn't realized account creation used the same form. Perhaps some conditional logic could be used to hide these buttons if the user hasn't yet been created, but show them so long as the user exists? There are other buttons already on the form that don't make a lot of sense during account creation which would be good to hide as well.

And @jboyer, I like the approach you propose, so long as only the relevant data is updated (not everything on the form) and the user sees some kind of confirmation like "Email updated" or "SMS Carrier updated" so they realize the change will stick even if they don't save the form. Of course, if it is easy to just do away with the need to save the data to the database that would be even better!