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?
+1
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.
(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.
Created attachment 147405 [details] [review] 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
Created attachment 147410 [details] [review] 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>
Works on all cylinders. Looks good!
Created attachment 150351 [details] [review] 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>
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?
(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. :)
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.
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.
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.
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.
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.
(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?
(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.
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.
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.
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.
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.