Closed JimMichael closed 12 months ago
Rock tries not to create multiple address(location) records with the same street address. This is to reduce standardization/geocoding costs. When you update a campus, Rock automatically adds/updates it's associated location record with the same name so that location will also show in the Named Locations list and allow you to add child buildings/rooms. When you set the global address to the same street address, instead of creating a duplicate location record, it uses the same location record used by the campus, and the address attribute's formatted value will first look to see if the location is named or not and if so, display the location's name (not the campus name). It's not actually "wiping" out the address, it's just displaying the name instead of the street address.
You'll notice too that when you update the campus name, the location name is getting updated too (see Named Location block).
It's really working as designed, but do you still feel there is a bug with that design, or is it causing an issue with the name being displayed somewhere instead of the street address?
Thanks for that detail, makes more sense now. However, I do now think the design is flawed. Where this issue surfaced for us is in the default email template, which inserts {{GlobalAttribute.OrganizationAddress}}, which in our case inserted the word "Chesterfield" instead of the (expected) actual address. Is this the intended use of this global attribute? I think any reasonable expectation of inserting that attribute into email is that it would expand to the actual agree address.
Yeah that would be a problem. We really can't just update the ToString()
behavior of Location as that could affect other areas that expect a named location to resolve as the name. You can update that lava to {% assign orgAddress = 'Global' | Attribute:'OrganizationAddress','Object' %}{{ orgAddress.FormattedAddress }}
to get the street address of a named location. Meanwhile, we'll look at how to best handle that in core.
I've honestly lost track of this issue, and I know I've asked before but don't recall the answer... is this also related to the way Check-in reports our Campus location as "114 N Eatherton Rd" instead of its name? (Chesterfield). We've been on check-in over a year and it still looks really odd to have it say "Jim was checked into 114 N Eatherton Rd, Chesterfield MO 63005" ;-)
@JimMichael is this still an issue or is it safe to close?
@JimMichael I tried to reproduce this on pre-alpha and it looks like the behavior is not working as you'd like. Steps:
Feel free to re-open with reproduction steps if you'd like.
We are seeing the following issue on 4.5:
Somehow when saving the Org Address Rock is seeing that we have a campus (location) with the same address and placing that campus name in the address attribute, wiping out the actual address. I have verified that entering an address that does NOT match a campus does not cause this issue.