We've had a number of bugs around patron name fields.. * Requests for additional fields * Requests for changes in display order * Requests for improved duplicate finding * Requests for improved table sorting I intend to collect opinions here and try to come up with a solution that suits more options.
In bug 21978 comment 9 Christopher Brannon suggests >What if we could just get away from the name structures, and have 5 or 6 generic >name fields (i.e. Name1, Name2, Name3 etc.), and we can label them in the editor >for whatever purpose we need, and on screens they appear in the order that they >are used. For example, Name1 is used as Surname, Name2 is First Name, Name3 is >Middle Name, and so on. Sort will always sort in order of the fields (Name1 >first, Name2 next, and so on), and would display similar to how they appear now: > >In results: >Name1, Name2 [Name3] [Name4] [Name5] [Name6] > >On patron account: >Name2 [Name3] [Name4] [Name5] [Name6] Name1 > I think this approach could work well, but it needs a little thought as to how it would work with de-duplicating and sorting and we may still need to implement display templating on top as currently you can call the patron-title include with various options for different displays in different places. I wonder if we could refine our display to a couple of more formal options.. 'short' and 'long' form perhaps.. right now we have various combinations of options in the template.. like including title or not, othernames, inverse ordering, cardnumber, linking.. etc etc
patron-title.inc currently allows for the following output formats * surname (othernames) * <span class="patron-title">title</span> surname, firstname (othernames) * <span class="patron-title">title</span> firtname (othernames) surname * title surname, firstname (othernames) * title firstname (othernames) surname * surname (othernames) (cardnumber) * <span class="patron-title">title</span> surname, firstname (othernames) (cardnumber) * <span class="patron-title">title</span> firtname (othernames) surname (cardnumber) * title surname, firstname (othernames) (cardnumber) * title firstname (othernames) surname (cardnumber) * cardnumber * <span>A patron from library [% Branches.GetName( patron.branchcode ) | html -%]</span>
*** Bug 24710 has been marked as a duplicate of this bug. ***
There was a try at doing this by surrounding name fields by spans, bug 24710, in the template includes, but it became clear that wasn't an option as the no_html option on the includes, used for title elements, precludes us from using said spans.
(In reply to Martin Renvoize from comment #2) > patron-title.inc currently allows for the following output formats > > * surname (othernames) > * <span class="patron-title">title</span> surname, firstname (othernames) > * <span class="patron-title">title</span> firtname (othernames) surname > * title surname, firstname (othernames) > * title firstname (othernames) surname > * surname (othernames) (cardnumber) > * <span class="patron-title">title</span> surname, firstname (othernames) > (cardnumber) > * <span class="patron-title">title</span> firtname (othernames) surname > (cardnumber) > * title surname, firstname (othernames) (cardnumber) > * title firstname (othernames) surname (cardnumber) > * cardnumber > * <span>A patron from library [% Branches.GetName( patron.branchcode ) | > html -%]</span> I like the idea of having clearer definitions on when to use what. Long, short, anonymous? The versions with span and without are for use in the title tag. And you'd probably still want title/no title. Probably would be nice to see how often each is used to see if we could replace one or another or if there is a good reason for them to be needed.
Here are some formats that would be appropriate for us: firstname surname firstname (other names) surname firstname (othernames) surname (cardnumber) As I look at it now, we really just want to be able to output names in a variety of formats without the title. (e.g. including "title" in the item status field in item detail.pl. is too much.) We are also an outlier in that we have repurposed the title field for pronouns. So this would also be desirable for us: firstname surname (title) I hope I'm answering the right question here. ;)
Hi Sarah, thx for weighing in. Just a note: 22.11 will have 2 new fields: pronouns and middle name. So you will be able to move from title to pronouns if you'd like.
Patron account display: It would be great if there were a way to hide particular name fields from patron account display pages. Example: A library uses "other name" for legal name when a patron goes by a different first name but the library needs to record the legal name as well. Currently, this displays as First (Other) Last. Staff only need to see first name and last name, out of respect for patron privacy and avoiding confusion. The library wants to hide the "other name" from all places where a patron name displays except for the account creation/editing screen. This could potentially be controlled with a system preference, something like "If using the Other Name field in patron records, show/hide Other Name."
Created attachment 175338 [details] [review] Bug 30568: Add classes to patron title components to test: 1 - have a patron with data in firstname, surname, middle name, othernames, and preferred name 2 - view patron name in patron record and other places where patron.title is used, confirm lack of HTML markup 3 - apply patch, restart services 4 - reload patron record and other pages around Koha, confirm name display hasn't changed but the composite parts of the name are now marked with classes
(In reply to Andrew Fuerste-Henry from comment #9) > Created attachment 175338 [details] [review] [review] > Bug 30568: Add classes to patron title components > > to test: > 1 - have a patron with data in firstname, surname, middle name, othernames, > and preferred name > 2 - view patron name in patron record and other places where patron.title is > used, confirm lack of HTML markup > 3 - apply patch, restart services > 4 - reload patron record and other pages around Koha, confirm name display > hasn't changed but the composite parts of the name are now marked with > classes I've only done the staff side here, though it shouldn't be hard to do the same on the OPAC. I've gone very minimal here, just inserting spans and classes around the different parts of the name. That should allow the local use of jQuery to further customize and reorder them all.
Created attachment 175351 [details] [review] Bug 30568: Add classes to name components in OPAC To test: 1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename) 2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts 3- apply patch 4- reload OPAC pages, observe name looks the same but now has classes when inspected
This breaks some strings where the no_html flag is passed. For example, go to the hold history for a patron with this applied and view the title element: <title>Holds history for <span class='preferred_name'>Ronnie</span> <span class='surname'>Ballard</span> <span class='cardnumber'>(23529000139858)</span> › Patrons › Koha</title> It's attempting to pass in HTML when it shouldn't.
Created attachment 175365 [details] [review] Bug 30568: Add classes to component name parts in intranet to test: 1 - have a patron with all name parts 2 - load pages with a variety of name displays, confirm lack of classes 3 - apply patch 4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
(In reply to Lucas Gass (lukeg) from comment #12) > This breaks some strings where the no_html flag is passed. For example, go > to the hold history for a patron with this applied and view the title > element: > > <title>Holds history for <span > class='preferred_name'>Ronnie</span> <span > class='surname'>Ballard</span> <span > class='cardnumber'>(23529000139858)</span> › Patrons › Koha</title> > > It's attempting to pass in HTML when it shouldn't. Updated the intranet patch to account for no_html. It doesn't look like a comparable flag exists on the OPAC. Here's the title of a hold history page without my patches: <title>Holds history for Jim Andrew (Ace) Acevedo (23529000035676) › Patrons › Koha</title> "› Patrons › Koha" seems to be there before my code.
Created attachment 175910 [details] [review] Bug 30568: Add classes to name components in OPAC To test: 1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename) 2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts 3- apply patch 4- reload OPAC pages, observe name looks the same but now has classes when inspected Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Created attachment 175911 [details] [review] Bug 30568: Add classes to component name parts in intranet to test: 1 - have a patron with all name parts 2 - load pages with a variety of name displays, confirm lack of classes 3 - apply patch 4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>