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
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.
It's actually worse than 5 minutes (or 1 min, which is what we set it to). If you have ever load tested TPS and pushed like 500 order emails into the queue, a user who requests a forgot password as they are processed is at the back of that queue. They can be the configuration value + all the time it takes TPS to process what is ahead of them.This is really, really crappy during a large onsale when a nervous patron has something in their cart and your seat timer is set to 11 mins and it takes 8 mins to get a reset password email.
As a relative newbie to Tessitura world, it's interesting to learn about this queue process and its limitations. On other software platforms I'm more familiar with, this would be solved with prioritized queues, where urgent, user-requested emails like password resets go into a high-priority, continuously running queue that would only get delayed by more than a few seconds due to an unusually high volume in the queue. Less sensitive emails like receipts would go into a lower-priority queue that could get processed every few minutes or as able when the high-priority queue is idle. I'm a little unclear why any kind of polling interval would be necessary though, as the queues I'm familiar with are continuously running processes that are throughput limited only by the number simultaneous queue workers, each running on a separate thread. Is the polling to help control server load? I would think a continuously running process would usually be less resource-intensive, since it's handling requests as they come in, not bunching them up in batches every few minutes.
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.