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 ]
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?
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.
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.
Created attachment 33520 [details] [review] 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)
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).
Patch tested with a sandbox, by scourret@gmail.com <2>
Created attachment 34304 [details] [review] DBRev 3.19.00.000: keep moving Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com> Signed-off-by: scourret@gmail.com <2>
Created attachment 34305 [details] [review] 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)
patch rebased, conflicts with bug 9177 fixed.
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
Created attachment 35577 [details] [review] 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>
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>
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.
(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.
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? :)
(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
Patch pushed to master. Thanks Owen!
Pushed to 3.18.x will be in 3.18.4