[Bug 31498] New: Allow for custom primary contact method values
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Bug ID: 31498 Summary: Allow for custom primary contact method values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: lucas@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com The values in the primary_contact_method dropdown on patron creation/edit are hard coded. Some libraries would like to include custom options in that dropdown. Maybe via Authorized Values? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewfh@dubcolib.org --- Comment #1 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- +1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31659 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #2 from Christopher Brannon <cbrannon@cdalibrary.org> --- +1 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 dgarr@cityoflewiston.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dgarr@cityoflewiston.org --- Comment #3 from dgarr@cityoflewiston.org --- I've been trying to add new values in primary_contact_method as well. I finally added some in JQuery: var myOptions = { val1 : 'Check', val2 : 'Call' }; var mySelect = $('#primary_contact_method'); $.each(myOptions, function(val, text) { mySelect.append( $('<option></option>').val(val).html(text) ); }); Unfortunately, these appear to be display-only, and not have any real value (they don't apply when the page is saved). Anyone have any insight? There has to be a work-around somewhere. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #4 from Lucas Gass <lucas@bywatersolutions.com> --- (In reply to dgarr from comment #3)
I've been trying to add new values in primary_contact_method as well. I finally added some in JQuery: var myOptions = { val1 : 'Check', val2 : 'Call' }; var mySelect = $('#primary_contact_method'); $.each(myOptions, function(val, text) { mySelect.append( $('<option></option>').val(val).html(text) ); }); Unfortunately, these appear to be display-only, and not have any real value (they don't apply when the page is saved). Anyone have any insight? There has to be a work-around somewhere.
The problem here is when you re-open the patron form to edit you cannot retrieve the custom value and it will be overwritten. Unfortunately you cannot currently retrieve the value from the REST API either. See Bug 28701. The best way forward is likely this enhancement request. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #5 from Lucas Gass <lucas@bywatersolutions.com> --- Created attachment 147405 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147405&action=edit Bug 31498: Make primary_contact_method values configurable This patch makes the primary_contact_method field configurable by tying the values to the new CONTACT_METHODS authorized value. To test: 1. Apply patch, updatedatabase, and restart_all 2. Now to go edit or create a new patron and check the 'Main contact method' dropdown. The values should be the same as they were previuosly. ( Primary phone, Secondary phone, Other phone, Primary email, Secondary email, and Fax ) 3. Try editing some patrons and changing these values, making sure they save correctly. 4. Go to the patron detail tab and make sure the correct values are displaying under 'Main contact method'. 5. Go to the OPAC and trying saving and changing the values on both the self registratin form and the modification form. 6. Now go to Administration > Authorized values > CONTACT_METHODS. Add some new CONTACT_METHODS. 7. With some ew values added try going through steps 3, 4, and 5 again. Make sure everything is displaying and saving correctly. 8. Make sure you can still hide and make required the primary_contact_method via these system prefs: BorrowerUnwantedField, PatronSelfModificationBorrowerUnwantedField, PatronSelfRegistrationBorrowerUnwantedField BorrowerMandatoryField, PatronSelfRegistrationBorrowerMandatoryField -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Assignee|koha-bugs@lists.koha-commun |lucas@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Biblibre Sandboxes <sandboxes@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147405|0 |1 is obsolete| | --- Comment #6 from Biblibre Sandboxes <sandboxes@biblibre.com> --- Created attachment 147410 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=147410&action=edit Bug 31498: Make primary_contact_method values configurable This patch makes the primary_contact_method field configurable by tying the values to the new CONTACT_METHODS authorized value. To test: 1. Apply patch, updatedatabase, and restart_all 2. Now to go edit or create a new patron and check the 'Main contact method' dropdown. The values should be the same as they were previuosly. ( Primary phone, Secondary phone, Other phone, Primary email, Secondary email, and Fax ) 3. Try editing some patrons and changing these values, making sure they save correctly. 4. Go to the patron detail tab and make sure the correct values are displaying under 'Main contact method'. 5. Go to the OPAC and trying saving and changing the values on both the self registratin form and the modification form. 6. Now go to Administration > Authorized values > CONTACT_METHODS. Add some new CONTACT_METHODS. 7. With some ew values added try going through steps 3, 4, and 5 again. Make sure everything is displaying and saving correctly. 8. Make sure you can still hide and make required the primary_contact_method via these system prefs: BorrowerUnwantedField, PatronSelfModificationBorrowerUnwantedField, PatronSelfRegistrationBorrowerUnwantedField BorrowerMandatoryField, PatronSelfRegistrationBorrowerMandatoryField Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off --- Comment #7 from Christopher Brannon <cbrannon@cdalibrary.org> --- Works on all cylinders. Looks good! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33218 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |aleisha@catalyst.net.nz |y.org | CC| |aleisha@catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #147410|0 |1 is obsolete| | --- Comment #8 from Aleisha Amohia <aleisha@catalyst.net.nz> --- Created attachment 150351 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=150351&action=edit Bug 31498: Make primary_contact_method values configurable This patch makes the primary_contact_method field configurable by tying the values to the new CONTACT_METHODS authorized value. To test: 1. Apply patch, updatedatabase, and restart_all 2. Now to go edit or create a new patron and check the 'Main contact method' dropdown. The values should be the same as they were previuosly. ( Primary phone, Secondary phone, Other phone, Primary email, Secondary email, and Fax ) 3. Try editing some patrons and changing these values, making sure they save correctly. 4. Go to the patron detail tab and make sure the correct values are displaying under 'Main contact method'. 5. Go to the OPAC and trying saving and changing the values on both the self registratin form and the modification form. 6. Now go to Administration > Authorized values > CONTACT_METHODS. Add some new CONTACT_METHODS. 7. With some ew values added try going through steps 3, 4, and 5 again. Make sure everything is displaying and saving correctly. 8. Make sure you can still hide and make required the primary_contact_method via these system prefs: BorrowerUnwantedField, PatronSelfModificationBorrowerUnwantedField, PatronSelfRegistrationBorrowerUnwantedField BorrowerMandatoryField, PatronSelfRegistrationBorrowerMandatoryField Signed-off-by: Christopher Brannon <cbrannon@cdalibrary.org> Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion CC| |tomascohen@gmail.com --- Comment #9 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Hi all. It feels to me that this should go the (say) debit types route, in which there are some system-defined ones the end user cannot remove, and then the user defined. What y'all think? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #10 from Lucas Gass <lucas@bywatersolutions.com> --- (In reply to Tomás Cohen Arazi from comment #9)
Hi all. It feels to me that this should go the (say) debit types route, in which there are some system-defined ones the end user cannot remove, and then the user defined. What y'all think?
I don't mind going this route but I would like some help deciding which ones should be system defined. We've had a request that to add 'Do not contact' which feels like it should be system defined. Also, I would raise my eyebrow if we kept 'fax' as a system defined value. :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #11 from Lucas Gass <lucas@bywatersolutions.com> --- While (In reply to Tomás Cohen Arazi from comment #9)
Hi all. It feels to me that this should go the (say) debit types route, in which there are some system-defined ones the end user cannot remove, and then the user defined. What y'all think?
While I don't mind going this route if that is what the community decides, I am of the opinion that these should be 100% configurable by libraries. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Juliet Heltibridle <jheltibridle@rcplib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jheltibridle@rcplib.org --- Comment #12 from Juliet Heltibridle <jheltibridle@rcplib.org> --- Our library hasn't started utilizing the main contact method yet, but it seems that phone, email & do not contact would make sense as system-defined options. But I don't really see a reason to have system defined options at all, since there aren't really any built-in automatic functions tied to this authorized value, like there are with the debit/credit types at this point. I am intrigued by the possibility of using "do not contact" to control some of our notices. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #13 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- I'm in favor of making these fully configurable, rather then having some contact methods hard-coded. I can't think of anything Koha does with this value that has the potential to fail if a library declines to use a specific contact method. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org --- Comment #14 from Michelle Spinney <mspinney@clamsnet.org> --- We would really like to have a Do Not Contact method in our network since we have patrons who come to the library daily. We'd also like to add SMS as a main contact method and have the ability to add new methods in the future. We're using the main contact method now so library staff know which holds can just be placed on the holdshelf and who they need to call. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Failed QA --- Comment #15 from Tomás Cohen Arazi <tomascohen@gmail.com> --- I see why y'all feel this should be completely arbitrary values: because it is only used for display purposes. The catch is this options: * phone * phonepro * mobile * email * emailpro * fax refer to real `borrowers.*` columns, so my fear is at some point someone will want to tie the *selected prefered contact method* value on that column, to a real behavior/function in Koha. So, thinking in advance, I feel like the current options should be presented a system-defined, which can also be disabled, and then we allow users to define their own. 'Do not contact' should be a default system option (value NULL). One drawback for this particular implementation is the contact methods are translatable (templates) right now. Moving them to the AV table will make them not-translatable or have every non-english install need to manually tweak the introduced AVs. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #16 from Aleisha Amohia <aleisha@catalyst.net.nz> --- (In reply to Tomás Cohen Arazi from comment #15)
I see why y'all feel this should be completely arbitrary values: because it is only used for display purposes.
The catch is this options:
* phone * phonepro * mobile * email * emailpro * fax
refer to real `borrowers.*` columns, so my fear is at some point someone will want to tie the *selected prefered contact method* value on that column, to a real behavior/function in Koha.
To be honest my thinking went this way too. If this field is simply information for the library and not tied to any behaviour or function in Koha - maybe it should just be a text field? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #17 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Tomás Cohen Arazi from comment #15)
I see why y'all feel this should be completely arbitrary values: because it is only used for display purposes.
The catch is this options:
* phone * phonepro * mobile * email * emailpro * fax
refer to real `borrowers.*` columns, so my fear is at some point someone will want to tie the *selected prefered contact method* value on that column, to a real behavior/function in Koha.
So, thinking in advance, I feel like the current options should be presented a system-defined, which can also be disabled, and then we allow users to define their own.
'Do not contact' should be a default system option (value NULL).
One drawback for this particular implementation is the contact methods are translatable (templates) right now. Moving them to the AV table will make them not-translatable or have every non-english install need to manually tweak the introduced AVs.
+1 I've had the same feeling looking at this and I think it's a good idea. If people want to hide some entries, which makes sense as we allow to hide any patron field, we could inherit that from BorrowerUnwantedFields maybe or have a separate visibility setting. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #18 from Lucas Gass <lucas@bywatersolutions.com> --- I don't know where to take this now. A couple of options have been mentioned: -Go the debit types route, making this its own page. Is that better for translations? -Make it a free text field. I took on this bug because I have had many requests to add custom values and requests to eliminate the current hard coded ones. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #19 from Lucas Gass <lucas@bywatersolutions.com> --- Also, adding values like 'Do not contact' will be confusing. Patrons will assume that marking themselves as 'Do not contact' will mean they will not be notices. As stated previously this field is simply informational. Marking oneself as 'Do not contact' will have no bearing on whether or not one receives a notice. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #20 from Christopher Brannon <cbrannon@cdalibrary.org> --- I think authorized values are the way to go. No hard coded values. Unless something is going to be tied to some automatic function down the road, and as long as this is informational only, admins can put whatever they want. However, if the goal is to tie this somehow to fields that have been filled out, maybe the choices are automatically filled in based off what contact methods have been filled out, and the authorized values is supplemental only. I would be in favor of the second choice, because it would automatically list what has only been supplied, and you only need to add what isn't usual or always want. However, I understand that this would make this a more challenging project. Plus, what happens if one of the built-in methods is selected and the patron has removed that method? Does it default to something else? If the second option is too difficult to implement, then I would definitely just go with the first. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 --- Comment #21 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- If we go the debit types route we can define "system internal" ones for the email, phone, phone_B etc. options that can be archived (removed from list if library decides to) and that we can add translations to the templates for. Then we don't have the additional ones translatable, but it's a good compromise I think. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 koha-US bug tracker <bugzilla@koha-us.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@koha-us.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Aleisha Amohia <aleisha@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|aleisha@catalyst.net.nz |testopia@bugs.koha-communit | |y.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Jessie Zairo <jzairo@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jzairo@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Jessie Zairo <jzairo@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lthorrat@cuyahogalibrary.or | |g -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31498 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|lucas@bywatersolutions.com |koha-bugs@lists.koha-commun | |ity.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org