Acquisitions - Validation rules

[George Duimovich]

EG version: 1.6
OpenSRF version: 1.2
PG version: 8.2
Ubuntu: Ubuntu 8.04.3 LTS

Perhaps not quite a bug, but an annoyance nonetheless.

In Acq > Providers > Provider Address, the constraints should imho be loosened up a bit.

Situation: Staff Client data entry

1. Enter a New Provider Address, and if you don't have a "State" value, it won't let you save your address (needs error feedback too). Seems too restrictive, since a) sometimes entering partial address details is better than no address details (for example, some online Providers make it hard for you to find their full physical address, but you may nonetheless know partial details about their business headquarters and wish to record them); and b) some addresses do not have any apparent State value. E.g. like say "Paris, France" or "Beijing 100029, China" or "Hong Kong, China" etc.

Additionally, the structure of some international addresses just reads differently, so I could imagine some Acq staff wanting to add a few addresses in a way that better approximates a proper mailing label structure. I see a number of examples internationally from our vendor file.

Situation: Migration

2. I am in the process of migrating our III vendor file into acq.provider and acq.provider_address - if you insert rows with some null values you get an error like "null value in column "state" violates not-null constraint" or ditto for "post_code" - Again this is problematic because some address details are better than none, and it also now requires too much clean up where in some records it may not be desirable or possible at this point in time.

For migration, my interim solution is to replace null values with a '-' and then I can batch import the providers addresses without violating constraints, etc. Easy to fix later on; for addresses added via Staff Client, we'll do the same for null fields.

Enhancement request:
In Provider details page, I would suggest that the first default tab to display is the "Provider Contact" tab rather than the "Provider Address" tab. It's likely the contacts details are what Acq staff want to see first over the Provider Address IMHO. Additionally, some redundancy with "Provider Address" versus "Provider Contact" Address IMO. Perhaps the Contact Address should allow one to default/use the main "Provider Address" A notes field would allow for details like our Account number, etc.

[Jason Stephenson (jstephenson)]

The bug has been hanging around for over two years with no progress. I assume, therefore, that it was only an issue in the 1.6 releases which are no longer supported.

[George Duimovich (george-duimovich)]

This still holds for 2.2.0 system.

Re: 1) & 2) above - workaround is to use "-" for null values.

Minor UI Enhancement request:

Looking at this again, I'd still suggest that the first tab (on left) be "Provider Contact" rather than "Provider Address" - most communication is by email / phone rather than by address, so having the default tab be Contact would save one click.

Opening separate ticket for another issue found in 2.2.0: https://bugs.launchpad.net/evergreen/+bug/1026168

[Jason Stephenson (jstephenson)]

Setting to New status since George reports it is still a problem in 2.2.0.

1) and 2) should probably be modified to allow null values.

The enhancement request should probably be a separate bug report.