Address placeholder data breaking Contact Point Purpose screen

Back in 2012, the decision was taken to use "" (two double quotes) as placeholder data in street1, city and postal_code when Customers created a new account on our website. The logic for this was that we only needed a Customer's address if they were purchasing tickets, and it was felt that adding an address slowed down the Customer's journey through the registration path if all they wanted to do was sign up for (say) email notifications about future productions.

This has now come back to bite us in that we have recently moved to Prospect2 and have migrated Contact Permissions to Contact Point Purposes. The CPP screen really does NOT like Address records that have "" as a placeholder - you get a standard "an error has occurred" screen which dumps you back to the Constituent Search screen. An additional gotcha to this is that you are unable to re-visit the Contact Details tab for that Customer because the last used Radio Button is "sticky" and the only solution is to retrieve a record that doesn't have the placeholders, navigate to a different Radio Button, and then load the original Customer.

Tessitura have replied in a ticket that this behaviour is not expected to change in a future release and that the solution would be to either turn off the "REQUIRE ADDRESS" setting (which we don't want to do for records created via the app) or change the values in T_DEFAULTS for "Default Street1", "Default City", "Default State" and "Default Postal_Code" to something that allows the CPP screen to not crash.

My question is: has anyone else experienced this, and if so what do they use as a placeholder?

Thanks

Parents
  • My question is: has anyone else experienced this,

    Back in 2014, Tess had a bug such that curly quotes in a notes field in Plans Maintenance would crash the client, and our Devo staff loved to paste text from Outlook (or was it Word), which used to default to that kind of quote char, into this field. Fun times. :-)

    Anyway, as Heath mentions, these troublesome chars can be UPDATE-ed away in SSMS, if that is available to you. We've used "99999" as a default street1, "Unknown" for a default City, etc., for a long time.

Reply
  • My question is: has anyone else experienced this,

    Back in 2014, Tess had a bug such that curly quotes in a notes field in Plans Maintenance would crash the client, and our Devo staff loved to paste text from Outlook (or was it Word), which used to default to that kind of quote char, into this field. Fun times. :-)

    Anyway, as Heath mentions, these troublesome chars can be UPDATE-ed away in SSMS, if that is available to you. We've used "99999" as a default street1, "Unknown" for a default City, etc., for a long time.

Children
No Data