Patron search results displays database id for physical and mailing addresses

[Kathy Lussier]

Evergreen version: 2.2 RC1
PostegreSQL: 9.1
Debian Squeeze

When the mailing address and physical address column picker options are selected on the patron search results screen, the system will display the database ID's for the addresses, not the actual addresses.

[Michael Peters (mrpeters)]

AFAIK Evergreen has always operated this way.

I think having the actual Street 1/2 address appear would be a valid feature request, though.

[Jason Etheridge (phasefx)]

> I think having the actual Street 1/2 address appear would be a valid
> feature request, though.

There are dedicated columns for exposing specific mailing and billing
address fields. We should probably hide/remove the original fields
that present just the ID's, but they could be useful for
troubleshooting.

-- Jason

[Michael Peters (mrpeters)]

I agree. They are helpful. Lets just rename them to indicate they are DB ID values?

[Michael Peters (mrpeters)]

Actually, it looks like they are already labeled "Mailing Addr: Address ID", for example, from master (2506f44). So, perhaps this is just invalid now?

[Jason Etheridge (phasefx)]

> Actually, it looks like they are already labeled "Mailing Addr: Address
> ID", for example, from master (2506f44). So, perhaps this is just
> invalid now?

Ah, that's a redundant column, so we should remove the original after
all. Each of the columns starting with a Mailing Addr: or Billing
Addr: prefix are actually being defined from a function called
fm_columns, that makes use of fm_IDL.xml. So as the IDL entry for
addresses change, so will the columns that show up in that interface.
But the original address columns that were defined for the existence
of fm_columns are still there, in patron/util.js, and that is where
you tweak things to remove the extra ID columns. Bite-sized bug.

[Michael Peters (mrpeters)]

Jason -- well, not quite, I don't think. They're not redundant in master. We only see the prefixed options. I think it's older versions that would need a column name change.

[Jason Etheridge (phasefx)]

On Mon, Oct 1, 2012 at 2:55 PM, Michael Peters <email address hidden> wrote:
> Jason -- well, not quite, I don't think. They're not redundant in
> master. We only see the prefixed options. I think it's older versions
> that would need a column name change.

It looks like they're still there, and I was wrong in my first guess
at how things worked. In master at least, we're solely using
fm_columns here. So we're getting fields for the "au" user object,
the "ac" library card, and for the "aua" mailing and billing
addresses. The "aua" columns will be the fleshed values for the
addresses, including ID (and we're prefixing the label for all of
these columns with Foo Address:). But the "au" object should also
include mailing and billing address columns, which would just contain
the ID, and those are the unprefixed labels, "Mailing Address" and
"Billing Address". It's not sorted, so they're easy to overlook.

I'm going to push a branch fixing this, since we really need a
remove_me option for fm_columns.

-- Jason

[Michael Peters (mrpeters)]

You're right, Jason. I was overlooking them because they are indeed out of alpha order. Thanks for looking and for the future fix!

[Jason Etheridge (phasefx)]

Two commits in this branch:
collab/phasefx/fm_columns_remove_me @ working/Evergreen.git
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/phasefx/fm_columns_remove_me

As a bonus, I added a flag for sorting the labels coming out of fm_columns, and have done this for the user columns in the Patron Search interface (but have left the columns for the library card and addresses unsorted--i.e. ordered as they are in fm_IDL.xml)

[Jennifer Pringle (jpringle-u)]

I have tested this code (against master) and consent to signing off on it with my email address, [<email address hidden>], and name, [Jennifer Pringle].

[Ben Shum (bshum)]

Thanks for testing Jennifer! I've added your signoff line to the commits and pushed them to master, rel_2_6, and rel_2_5.