Bug 30568 - Make patron name fields more flexible
Summary: Make patron name fields more flexible
Status: Patch doesn't apply
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Andrew Fuerste-Henry
QA Contact: Testopia
URL:
Keywords:
: 24710 (view as bug list)
Depends on: 30617
Blocks: 7680
  Show dependency treegraph
 
Reported: 2022-04-20 08:47 UTC by Martin Renvoize (ashimema)
Modified: 2025-03-07 08:40 UTC (History)
11 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 30568: Add classes to patron title components (3.32 KB, patch)
2024-12-09 22:01 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 30568: Add classes to name components in OPAC (1.71 KB, patch)
2024-12-10 14:03 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 30568: Add classes to component name parts in intranet (4.52 KB, patch)
2024-12-10 18:30 UTC, Andrew Fuerste-Henry
Details | Diff | Splinter Review
Bug 30568: Add classes to name components in OPAC (1.77 KB, patch)
2024-12-23 14:56 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 30568: Add classes to component name parts in intranet (4.58 KB, patch)
2024-12-23 14:56 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize (ashimema) 2022-04-20 08:47:42 UTC
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.
Comment 1 Martin Renvoize (ashimema) 2022-04-20 09:01:25 UTC
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
Comment 2 Martin Renvoize (ashimema) 2022-04-20 09:26:30 UTC
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>
Comment 3 Martin Renvoize (ashimema) 2022-04-27 06:56:03 UTC
*** Bug 24710 has been marked as a duplicate of this bug. ***
Comment 4 Martin Renvoize (ashimema) 2022-04-27 06:59:04 UTC
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.
Comment 5 Katrin Fischer 2022-11-17 12:54:01 UTC
(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.
Comment 6 Sarah Cornell 2022-11-19 15:53:35 UTC
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.  ;)
Comment 7 Katrin Fischer 2022-11-19 18:07:52 UTC
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.
Comment 8 holly 2024-08-26 21:44:03 UTC
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."
Comment 9 Andrew Fuerste-Henry 2024-12-09 22:01:19 UTC
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
Comment 10 Andrew Fuerste-Henry 2024-12-09 22:02:45 UTC
(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.
Comment 11 Andrew Fuerste-Henry 2024-12-10 14:03:28 UTC
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
Comment 12 Lucas Gass (lukeg) 2024-12-10 14:56:26 UTC
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 &lt;span class='preferred_name'&gt;Ronnie&lt;/span&gt; &lt;span class='surname'&gt;Ballard&lt;/span&gt; &lt;span class='cardnumber'&gt;(23529000139858)&lt;/span&gt; › Patrons › Koha</title>

It's attempting to pass in HTML when it shouldn't.
Comment 13 Andrew Fuerste-Henry 2024-12-10 18:30:42 UTC
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
Comment 14 Andrew Fuerste-Henry 2024-12-10 18:32:25 UTC
(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 &lt;span
> class='preferred_name'&gt;Ronnie&lt;/span&gt; &lt;span
> class='surname'&gt;Ballard&lt;/span&gt; &lt;span
> class='cardnumber'&gt;(23529000139858)&lt;/span&gt; › 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) &rsaquo; Patrons &rsaquo; Koha</title>

"&rsaquo; Patrons &rsaquo; Koha" seems to be there before my code.
Comment 15 Lucas Gass (lukeg) 2024-12-23 14:56:25 UTC
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>
Comment 16 Lucas Gass (lukeg) 2024-12-23 14:56:28 UTC
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>