Bug 5749 - The display of borrower adresses composed of streetnumber, streettype and address is broken
Summary: The display of borrower adresses composed of streetnumber, streettype and add...
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: 3.8
Hardware: All All
: P4 normal (vote)
Assignee: Stéphane Delaune
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks: 5575
  Show dependency treegraph
 
Reported: 2011-02-13 22:07 UTC by Chris Cormack
Modified: 2013-12-05 19:59 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed Patch (4.53 KB, patch)
2011-02-13 22:25 UTC, Chris Cormack
Details | Diff | Splinter Review
Followup patch (5.74 KB, patch)
2011-02-13 22:26 UTC, Chris Cormack
Details | Diff | Splinter Review
proposed patch (updated) (3.75 KB, patch)
2011-08-04 13:38 UTC, Paul Poulain
Details | Diff | Splinter Review
proposed patch (updated) (1.58 KB, patch)
2012-03-06 15:25 UTC, Stéphane Delaune
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 5749 Fix borrower address display in intranet (1.68 KB, patch)
2012-03-09 17:39 UTC, Owen Leonard
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2011-02-13 22:07:58 UTC
This manifests in the staff client
Comment 1 Chris Cormack 2011-02-13 22:25:14 UTC Comment hidden (obsolete)
Comment 2 Chris Cormack 2011-02-13 22:26:08 UTC Comment hidden (obsolete)
Comment 3 MJ Ray (software.coop) 2011-03-06 12:10:20 UTC
This bug is mentioned in:
Bug 5749 Fix borrower address display in	intranet http://lists.koha-community.org/pipermail/koha-patches/2011-February/013842.html
Bug 5749 follow up patch, whitespace cleanup http://lists.koha-community.org/pipermail/koha-patches/2011-February/013843.html
Bug 5749 Fix borrower	address display in intranet http://lists.koha-community.org/pipermail/koha-patches/2011-February/013852.html
Comment 4 Chris Cormack 2011-03-14 04:30:52 UTC
This has been signed off by Salvador Zaragoza Rubio
Comment 5 Chris Cormack 2011-03-14 08:36:15 UTC
Pushed for QA

new/bug_5749
Comment 6 Ian Walls 2011-08-02 17:47:46 UTC
I'm not clear what the nature of the problem is, so it's difficult for me to evaluate the patch.  Could a summary of the display breakage be given, as well as the circumstances required to bring it about?  Screenshots encouraged.
Comment 7 Chris Cormack 2011-08-03 02:13:17 UTC
Paul, (or someone from biblibre) any more information on this?
Comment 8 Paul Poulain 2011-08-03 07:58:11 UTC
BibLibre Mantis number = 1416 (reported by SAN-OP)

lorsqu'on utilise les zones de saisie numéro de voie et type de voie,
l'adresse n'est pas correctement affichée sur la liste de recherche d'un
adhérent ainsi que sur la fiche de l'adhérent

=> when you use streetnumber / streetype, the address is not correctly displayed on the patron result list and on the borrower detail.

HTH
Comment 9 Paul Poulain 2011-08-04 13:38:40 UTC Comment hidden (obsolete)
Comment 10 Ian Walls 2011-08-05 12:27:29 UTC
Comment 8 still does not provide a clear explanation of what the problem actually is.  What does "not correctly displayed" mean?  How does it display now, and how SHOULD it display?  What data in what order?  Screenshots would be helpful.
Comment 11 Paul Poulain 2011-08-05 12:48:34 UTC
Ian:
if you use street type and streetnumber, an address like "108 rue Breteuil" has
108 in streetnumber
rue in streettype
Breteuil in address

Before this patch the display is
BibLibre
Breteuil
13006 Marseille

After this patch the display is correct :
BibLibre
108 rue Breteuil
13006 Marseille

If you store everything in address, the patch has no consequence, it's displayed "108 rue Breteuil" as address="108 rue Breteuil" and streetnumber/streettype are empty

Is it clear now ?
Comment 12 Ian Walls 2011-08-05 12:58:33 UTC
Paul,

Yes, very clear now, thank you.  Patch can now be evaluated against a test condition.
Comment 13 Owen Leonard 2011-08-05 17:11:52 UTC
Is attachment 3139 [details] [review] obsoleted by attachment 4843 [details] [review]?

Many of the changes in attachment 4843 [details] [review] are also in the patch for Bug 5436. I'll consider this the feature-specific bug for the address display changes and remove them from Bug 5436.
Comment 14 Stéphane Delaune 2012-03-06 15:25:28 UTC Comment hidden (obsolete)
Comment 15 Owen Leonard 2012-03-09 17:39:28 UTC
Created attachment 8126 [details] [review]
[SIGNED-OFF] Bug 5749 Fix borrower address display in intranet

Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Comment 16 Owen Leonard 2012-03-09 17:44:38 UTC
I notice there are other problems with displaying addresses this way. For instance, circulation.pl and moremember.pl both use the same include file (circ-menu.inc), but only in circulation.pl does the [% address %] variable get built using street type, street number, and address:

my $address = $borrower->{'streetnumber'}.' '.$roadttype_hashref->{$borrower->{'streettype'}}.' '.$borrower->{'address'};

I wonder why we're not doing this in the template instead?
Comment 17 Paul Poulain 2012-03-14 14:29:11 UTC
QA comment: tiny patch, passed QA

(In reply to comment #16)
> I notice there are other problems with displaying addresses this way. For
> instance, circulation.pl and moremember.pl both use the same include file
> (circ-menu.inc), but only in circulation.pl does the [% address %] variable
> get built using street type, street number, and address:
> 
> my $address = $borrower->{'streetnumber'}.'
> '.$roadttype_hashref->{$borrower->{'streettype'}}.' '.$borrower->{'address'};
> 
> I wonder why we're not doing this in the template instead?

I think there's no specific reason to do it that way.
Maybe that's a topic for next week, and defining "object" that will make a consistent display
Comment 18 Paul Poulain 2012-03-14 15:15:11 UTC
follow-up pushed directly onto master, as the original branch new/bug_5749 was pre-3.4, so HTML::Template and the patch can't apply anymore
Comment 19 Jared Camins-Esakov 2012-05-09 16:57:01 UTC
This bug will be included in the Koha 3.6.5 release.