Hi Paul, Our idea is to completely stop having to add the '0' before the actual postcode, as quite a few staff forget to enter it whilst entering a patrons details, and then they get the error message about the entry.. it can be a bit troublesome if you have to enter a new patrons details and also have a que lining up at the Circ desk, since our Enquiry and Circ desk are combined.
Kindest Regards, Joel On Wed, May 19, 2010 at 11:06 AM, Paul Bartell <[email protected]>wrote: > I suspect doing a giant database query would solve the problem, and > fix the need for future entries. modifying the report output might be > the simplest solution though. > > On Tue, May 18, 2010 at 6:00 PM, Bill Ott <[email protected]> wrote: > > > > > > On 5/18/10 8:42 PM, Joel Harbottle wrote: > > > > <snip> > > > > Is there an ultra-easy way in Evergreen to fix this post code problem, to > > allow Evergreen to accept a 4 digit postcode, such as 7250. > > > > Might depend on your definition of ultra-easy, but it's certainly > possible > > without a major change. > > > > Locate ue_config.js. Likely under: > > /openils/var/xul/<build_id>/server/patron/ue_config.js > > > > Within this file is the regular expression that matches on the postal > code > > entry: > > const zipRegex = /^\d{5}(-\d{4}|-?$)/; /* 12345 or 12345-6789 > */ > > > > If you want it to require a 4 digit number, change this line to: > > const zipRegex = /^\d{4}/; > > > > > > > > > > As well as the postcode problem is there an ultra-easy to change the > layout > > of the postal address when it is printed, so it is in the standard for > > postal addresses here in Australia. > > > > I'm not certain where this print is coming from. I expect it's a similar > > change, but will need a bit more information to know where that change > needs > > to be made. > > > > > > > > (Example below): > > > > Mr Joe Bloggs > > 101 Example Street > > LAUNCESTON TAS 7250 > > Australia > > > > (On the postal address printout, we don't need 'Australia' to show, as we > > are only posting locally.) > > > > Our library has had this problem since we migrated to Evergreen two years > > ago. We migrated to Evergreen 1.2.0.4, and are now using Evergreen > 1.4.0.6, > > and have had this problem since 1.2.0.4. > > > > Our library is also planning to upgrade to Evergreen 1.6 in the next two > > months. But since this is a major disruption to our workflow, this needs > > fixing in 1.4.0.6, as we are unable to spare the time to wait til our 1.6 > > upgrade. > > > > Kindest Regards, > > Joel > > > > > > Joel Harbottle > > Email: [email protected] > > > > > > -- > Random quote of the week/month/whenever i get to updating it: "Quis > custodiet > ipsos custodes?": "who shall watch the watchers themselves?" - Juvenal >
