Bug 13142 - Change "mobile phone" label back to "other phone"
Summary: Change "mobile phone" label back to "other phone"
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Templates (show other bugs)
Version: master
Hardware: All All
: P5 - low normal (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-24 15:52 UTC by Owen Leonard
Modified: 2016-12-05 21:23 UTC (History)
10 users (show)

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


Attachments
Bug 13142 - Change "mobile phone" label back to "other phone" (7.22 KB, patch)
2014-11-13 13:52 UTC, Owen Leonard
Details | Diff | Splinter Review
DBRev 3.19.00.000: keep moving (1.40 KB, patch)
2014-12-11 10:01 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 13142 - Change "mobile phone" label back to "other phone" (7.24 KB, patch)
2014-12-11 10:31 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 13142 - Change "mobile phone" label back to "other phone" (7.25 KB, patch)
2015-01-28 13:14 UTC, Marcel de Rooy
Details | Diff | Splinter Review
[PASSED QA] Bug 13142 - Change "mobile phone" label back to "other phone" (7.28 KB, patch)
2015-01-30 12:00 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Leonard 2014-10-24 15:52:52 UTC
Bug 12407 changed the "other phone" label to "mobile phone." However I think this conflicts with the changes made by Bug 5252 which changed the labels to the more generic "primary," "secondary," and "other" with the intention of letting the patron choose a primary contact number regardless of what kind of phone it is.

If the OPAC didn't reflect this change then that was a bug which should have been fixed as a follow-up to 5252.

As for the fact that the database column name says "mobile," I don't think that should dictate what kind of data we are storing.

At this point we've created a lot of confusion about how patron contact information is stored. Before August 2011 phone data may have been entered according to the specific "home," "work," and "cell" labels. After that date we can assume that new phone data was added according to the priority defined by the new labels.

Now with Bug 12407 we have a mix: Two phone fields in which the patron can prioritize contact numbers, and then "mobile," which is very specific.

I don't think this makes sense. In my opinion the correct action at this point is to revert the label change made by Bug 12407 and make the corresponding change to the OPAC.

If we feel that it's necessary to be able to identify what *kind* of phone number each one is, perhaps the solution is to add new columns to borrowers which can contain authorized values defining phone types:

Primary phone: _________ [ Home | Work | Mobile | Etc ]
Comment 1 Marcel de Rooy 2014-10-24 20:26:26 UTC
Hi Owen,
Your comment makes sense to me. However as long as the names in the table will be phone, mobile, phonepro, B_phone, smsalertnumber the confusion will not end by renaming labels once again.
Do we really need so many phone numbers to contact a patron btw?
Comment 2 Liz Rea 2014-10-30 02:29:21 UTC
Yes, unfortunately we do need all of the numbers. Flexibility (for libraries, in this case) is a feature, not a bug. 

Since we can hide the fields in the borrower input and display using system preferences, I'm utterly opposed to removing any of them.
Comment 3 Owen Leonard 2014-11-12 19:56:46 UTC
Note that in the OPAC the label went from "Other phone" after Bug 5252 back to "Mobile phone" when we added online patron self-registration--a change I assume was made because the new template was based on a version of the template pre-Bug-5252.
Comment 4 Owen Leonard 2014-11-13 13:52:34 UTC Comment hidden (obsolete)
Comment 5 David Cook 2014-11-26 03:11:43 UTC
This is a good point. It always drives me nuts when I'm filling out forms that say "Primary, Secondary, Mobile", as my mobile is always my primary number.

"Primary, Secondary, Other" probably makes the most sense.

*consults phone*

In my phone's contact list, I insert a number and then I can choose a label for that number. I can even have two mobile numbers if I want.

Admittedly, in that case, I get to decide myself what number matters most. I'm not sending out automated phone notifications or anything like that.

Honestly, if the database were more normalized, we'd have a borrower_phone_number table with columns something like: "phone_number_id","borrowernumber" (FK), "phone_number", "type".

Maybe even have another column for "primary" or "priority" (so you can choose primary, secondary, whatever).

You could do the same thing for "borrower_email": "email_id","borrowernumber" (FK), "email_address", "type", "priority" (or probably a better label than priority).

If we wanted to make it even more flexible, we could just have "email" and "phone_number" tables and have columns to determine whether it's for a library or a patron (or maybe some other organization/group/listserv).

Koha isn't a very normalized database which causes a fair amount of pain sometimes (that said, highly normalized databases can also be painful).

Of course, if we did that, we'd need to change everywhere that we add/edit/view/send to email addresses and phone numbers, and who has that kind of time.

--- 
tldr;

In any case, I agree with what I think Owen is saying. The label doesn't really matter. It's the importance (i.e. whether or not it's primary) that matters. 

Locally, we often change the label using jQuery anyway, but the important one is always the first one during data entry (at least with newer clients... older clients will be tied a bit more to the email vs emailpro model which is a bit tedious).
Comment 6 Biblibre Sandboxes 2014-12-11 10:01:27 UTC
Patch tested with a sandbox, by scourret@gmail.com <2>
Comment 7 Biblibre Sandboxes 2014-12-11 10:01:46 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2014-12-11 10:31:06 UTC Comment hidden (obsolete)
Comment 9 Jonathan Druart 2014-12-11 10:31:38 UTC
patch rebased, conflicts with bug 9177 fixed.
Comment 10 Courret 2014-12-11 15:04:43 UTC
CSV Export from DB displays phone (for primary phone), phonepro (for secondary phone) and mobile (for other phone) as column names.
OPAC displays correctly the different phone number types. The patron can change his details using the OPAC. Unfortunately, these changes can't be validated by the librarians : click on "submit" in the update patron record page makes no changes in the DB (same issue on a 3.14). 

 - OPAC "your personal details" (opac-memberentry.pl) -> OK
 - Submit changes to primary, secondary, and other phone via the OPAC. -> OK
   In the staff client, view the confirmation for those changes. -> Fail. Confirmation can be seen but no validation can be made. Tested on differents accounts. 
 - Patron details in the staff client (moremember.pl) -> OK
 - Patron entry/edit in the staff client (memberentrygen.pl)-> OK
 - Patron duplicate confirmation in the staff client -> OK
Comment 11 Marcel de Rooy 2015-01-28 13:14:27 UTC Comment hidden (obsolete)
Comment 12 Kyle M Hall 2015-01-30 12:00:27 UTC
Created attachment 35615 [details] [review]
[PASSED QA] Bug 13142 - Change "mobile phone" label back to "other phone"

Labeling a phone number field "mobile phone" eliminates the usefulness
of having the labels "primary" and "secondary." Generic labels let the
user populate the fields according to their importance rather than their
type.

To test I recommend editing a patron record so that the values in the
patron record contain a label matching the table column:

borrowers.phone : 555-555-1234 (primary - phone)
borrowers.phonepro : 555-555-5678 (secondary - phonepro)
borrowers.mobile : 555-555-9012 (other - mobile)

View this patron's information in the various affected templates and
verify that the labels correctly match the data:

 - OPAC "your personal details" (opac-memberentry.pl)
 - Submit changes to primary, secondary, and other phone via the OPAC.
   In the staff client, view the confirmation for those changes.
 - Patron details in the staff client (moremember.pl)
 - Patron entry/edit in the staff client (memberentrygen.pl)
 - Patron duplicate confirmation in the staff client
   (you can navigate directly to
   /members/moremember.pl?borrowernumber=XXXX&print=brief)

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Comment 13 Tomás Cohen Arazi 2015-02-09 17:06:49 UTC
We should just stop doing this, and use normalized data... with a proper borrower_phone table... with a column labeled 'type'... a 'primary' checkbox... and allow users to have an arbitrary number of phone numbers. And show them with a pretty icon depicting the type of phone...

Just saying.
Comment 14 David Cook 2015-02-11 23:17:28 UTC
(In reply to Tomás Cohen Arazi from comment #13)
> We should just stop doing this, and use normalized data... with a proper
> borrower_phone table... with a column labeled 'type'... a 'primary'
> checkbox... and allow users to have an arbitrary number of phone numbers.
> And show them with a pretty icon depicting the type of phone...
> 
> Just saying.

Agreed! I seem to recall saying the same thing on an older bug report. 

We'd want to do the same thing with email addresses as well. 

Also mailing addresses.

Fax would probably be included in the phone table...

Contacts should also be normalized...

Really a lot of the data in the borrowers table should probably be moved out into their own tables.
Comment 15 Katrin Fischer 2015-02-12 06:16:41 UTC
I think that would be quite a rewrite involving lots of code, patron import and every page where we show address information/phone numbers. But should this reallybe blocking this patch? :)
Comment 16 Tomás Cohen Arazi 2015-02-12 14:17:31 UTC
(In reply to Katrin Fischer from comment #15)
> I think that would be quite a rewrite involving lots of code, patron import
> and every page where we show address information/phone numbers. But should
> this reallybe blocking this patch? :)

Not a blocker, "just saying" :-D
Comment 17 Tomás Cohen Arazi 2015-02-13 17:13:40 UTC
Patch pushed to master.

Thanks Owen!
Comment 18 Chris Cormack 2015-02-14 08:24:09 UTC
Pushed to 3.18.x will be in 3.18.4