Hi -- In Tessitura, the Example Login Credentials email template has this code:
@if (Model.GetPropertyValue("ResetLink") != null){ <p> <a href="@Model.GetPropertyValue("ResetLink")" target="_blank">Click here to reset your password</a> </p>}
Can someone tell me where that property value comes from?
Searching the tessituranetwork.com site for "ResetLink" yields no results.
Thanks!
-- Alan
Hi Alan,
It's a template parameter. It's included in that template as an example of how parameters work. If you are making other edits to the template, you could certainly hardcode the URL into the template instead.
Also, am I reading correctly that emails are only going to be sent once every five minutes? That seems like an inordinate amount of time to wait for a lost password reset.
All HTML templates are managed on a queue process, including login credentials, order confirmations, and mobile tickets. The polling frequency of the queue can be changed in the settings of the Tessitura Processing Service, and we do currently recommend setting this at 5 minutes. I do take your point about waiting for a Forgot Login email and I will raise it with our teams.
I view immediate delivery of Forgot Login emails essential. I know if no online e-commerce site I regularly do business with as a consumer where those do not arrive almost immediately. It’s what patrons will be expecting (and rightfully so).
I already voted these up, but seconded/thirded/whatever. Forgot Login should be as near instant as possible for the customer experience. Same as Nick said regarding client side e-mails when you are talking to to someone. Web orders? Eh, I can take a few minutes on those. Patrons do not necessarily need the confirmation within 30 seconds. A minute or two is fine there.
I am a patient man; 5 minutes is fine for most things with me. But 5 minutes does seem like a long time in this internet heavy/instant response world. And we know that patrons love to push things that we think should be "good enough".
More upvote for near-instantaneous password reset, especially if the password reset in the Contact Details > Logins > Forgot Login goes in the same up-to-five-minutes queue because tying up staff in the wait-time as well as the patron double ugh.
Michael--here are some results from when I tested TPS a few months back.
I inserted 400 concurrent password resets into the queue table. The first one was sent 18 seconds later. The last one came across 7+ mins later:queue time: 2021-03-24 10:11:05.077 process time: 2021-03-24 10:18:28.420
These forgot password resets should really be sent concurrently and not queued up.
Thanks so much Patrick (and everyone else) for the suggestion. I included this thread in the enhancement request that I logged based on this discussion. We appreciate knowing how important this is to everyone, and our developers will review it.
Has there been any movement on this? By the time my lost password email arrives, I've moved on to other things.