**self-hosted**
My coworker has requested that I disable PAH in the TEST environment. Up to this point all I have ever done is save a new copy do the template for LIVE. Can anyone point me to the documentation on have to turn it on or off?
Ashley Elliott
Database Administrator
St. Louis Symphony Orchestra
314-286-4198
ashleye@slso.org
Hi Ashley!
The quick way would be to inactivate all rows in TR_PAHT_CONFIGURATION. This is helpful for temporarily turning it off, but it would be overwritten in a live to test copy.
The long-lasting way would be to launch the instance of TIM for your Test environment. (Or your single instance of TIM, with your Test environment config file imported.) Go to Windows Services > Processing Service. Go to Print at Home > Email Settings > On/Off and set this to Off. Save your changes. Then reinstall the Processing Service.
Jerry - That is definitely correct, but I would also go into TIM for your Test environment, disable the setting, and save your changes. That way the config file and TIM are in sync, and you won't accidentally reenable it if you reinstalled your Processing Service, such as during a service pack upgrade.
My first question is, "Why do you want to turn off PAHT in Test?". We like having it available for testing.
In my experience, it's primarily to prevent accidentally sending emails to real customers. This can happen if someone places an order for a customer (like training a box office user, testing something unrelated, etc.), or when you complete a live to test copy and you happen to catch an unprinted PAH order that gets processed in Test. Not only could this be unexpected or confusing for a customer, but they may inadvertently keep and use the Test ticket in the Production environment, and that can lead to all kinds of confusion for everyone.
Ashley and Jerry may have additional reasons to share as well.
They're still going to get confirmation emails and password reset emails, which seems bad enough. Also, testing ticket sales and PAHT delivery are part of our standard upgrade testing scripts.
We rarely use actual customer accounts for testing, but to really prevent that from happening I mangle all customer emails in Test. We use Gmail for our mail service, and so I take the email address, replace the "@" with a "+", then insert it into an internal email: [internal username]+[mangled customer email]@calperformances.org.
For added identification (and filtering) we change all of our FROM and BCC addresses in Test to use a labeled alias (i.e. confirmations-test@ instead of confirmations@)
With regular tickets we have a design element that looks at campaign name, and if it detects the control character ("|" for us) in front, then it covers the ticket with "VOID". Part of our Live->Test post copy scripting prepends all ticketing campaign names with the character. Alas you can't do conditionals in PAHT ticket designs, but one could consider just having two templates. We haven't bothered as the email address mangling covers us fairly well.
We're moving to Mobile Tickets (although, spoiler, they don't send well in the client currently) where, again, the email change generally protects us, but at some point I might want to revisit security around the tickets themselves.
When we were self-hosted we did try setting up test emails (and even the website itself) to only be available on our internal network, but found that it limited the scope of our testing too much (and would have been a nightmare for us during the last year...) Many of us work remotely now, and when we make big systemic changes or introduce new features we like to recruit community members to assist in our testing and give us feedback.
Thank you so much!
Ashley