Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Undocumented Change? | Address Display Name must now be unique

45 views
Skip to first unread message

BrianS

unread,
Dec 9, 2024, 11:42:42 AM12/9/24
to XMPie Interest Group
We've had a support case open on this since 11/26, but no concrete reply from Support.

A customer reached out after our update from uStore v10 to v18, stating that previously they were able to have the same Display Name used for multiple records in the address book with different shipping addresses. They're now required to make those display names Unique when creating a new address.

If that's a change, it makes complete sense to me. 

But, the problem is it appears to be an undocumented change. We've looked through the release notes going back to v10, and I can't find anything specifying this was changed. Could anyone here confirm what / if this behavior was changed?

Using SQL, I can see that there ARE duplicate Display Names in the Address Table.

SELECT DisplayName,PersonName, COUNT(*) as [Count]
FROM Address
where AddressTypeID = 1
GROUP BY DisplayName,PersonName
HAVING COUNT(*) > 1
order by [COUNT] DESC

(this is the entire table, not checking for duplicates associated with a single UserID)

In Version 18, When a Display name already exists in the Address table for a given UserID, an error message is displayed. If the Display Name is Omitted, the system will create it by concatenating the Name, Country, State, City. If those happen to be the same as another entry then an error will occur.

It looks like it is / was possible to have the same display name at some point. I do have duplicate records in my DB where the UserID is the same. This is the Query I used to find those.

select a.DisplayName, a.UserID
from Address a
Join (SELECT DisplayName,UserID
from Address
Group By DisplayName, UserID
Having count(*) >1) b
On a.DisplayName = b.DisplayName
--and a.email = b.email
where AddressTypeID = 1
order by a.displayName, UserID

This customer is also reporting that addresses that were previously entered are no longer there. I have yet to validate this behavior, but that could be a larger issue for us. If that's an unintended consequence of this change.

It'd be great if someone could sanity check my SQL and thought process on determining if the App changed, or perhaps my customer is confused.

couch

unread,
Dec 9, 2024, 4:16:57 PM12/9/24
to XMPie Interest Group
I don't know if there was a change, but I can confirm that uStore 18 does not allow a user to create more than one address with the same display name.

If it was permitted before, then I suspect that there were probably people complaining that when they checkout, the billing/shipping addresses are selected from a dropdown, and having multiple addresses with the same display name in the drop down was too confusing.

Also, there is no database constraint on the display name field because it would need to be possible for multiple uStore users to create an address with the same display name. Meaning that the validation is in application not the database.

west-digital.fr

unread,
Dec 10, 2024, 3:52:32 AM12/10/24
to XMPie Interest Group
Based on our experience, it has been a while, since the "Display Name" in uStore Addresses has been made mandatory by XMPie.
At least since 15.1 - we operate a uStore with this version in the name of a given customer, where we can already see this behavior.
I agree that, since the Release Notes have moved to a public web page, they may be less "technical" and less detailed, than they used to be, when they were a more discrete PDF file.
I also agree that doing such a "giant leap" from 10.0 to 18.0 cannot come without [good and] bad surprises.
When we face such situations here, we sometimes prefer doing a series of "small steps" instead, upgrading from 10 to 11, 11 to 12, etc. until 18. Obviously, its a longer and more annoying task, but database consistency sometimes worth it.

Reply all
Reply to author
Forward
0 new messages