Bug 31498 - Allow for custom primary contact method values
Summary: Allow for custom primary contact method values
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Lucas Gass
QA Contact: Aleisha Amohia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-31 15:58 UTC by Lucas Gass
Modified: 2023-10-26 16:42 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 31498: Make primary_contact_method values configurable (17.34 KB, patch)
2023-02-24 21:05 UTC, Lucas Gass
Details | Diff | Splinter Review
Bug 31498: Make primary_contact_method values configurable (17.40 KB, patch)
2023-02-24 22:55 UTC, Biblibre Sandboxes
Details | Diff | Splinter Review
Bug 31498: Make primary_contact_method values configurable (17.46 KB, patch)
2023-04-28 03:56 UTC, Aleisha Amohia
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Gass 2022-08-31 15:58:17 UTC
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?
Comment 1 Andrew Fuerste-Henry 2022-09-29 20:40:53 UTC
+1
Comment 2 Christopher Brannon 2023-02-07 21:46:35 UTC
+1
Comment 3 dgarr 2023-02-24 01:54:06 UTC
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.
Comment 4 Lucas Gass 2023-02-24 17:56:16 UTC
(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.
Comment 5 Lucas Gass 2023-02-24 21:05:06 UTC
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
Comment 6 Biblibre Sandboxes 2023-02-24 22:55:52 UTC
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>
Comment 7 Christopher Brannon 2023-02-24 22:57:06 UTC
Works on all cylinders.  Looks good!
Comment 8 Aleisha Amohia 2023-04-28 03:56:35 UTC
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>
Comment 9 Tomás Cohen Arazi 2023-05-16 13:15:42 UTC
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?
Comment 10 Lucas Gass 2023-06-29 14:35:33 UTC
(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. :)
Comment 11 Lucas Gass 2023-06-29 14:37:48 UTC
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.
Comment 12 Juliet Heltibridle 2023-06-29 15:08:15 UTC
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.
Comment 13 Andrew Fuerste-Henry 2023-06-29 15:44:05 UTC
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.
Comment 14 Michelle Spinney 2023-06-29 15:56:43 UTC
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.
Comment 15 Tomás Cohen Arazi 2023-06-29 17:45:14 UTC
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.
Comment 16 Aleisha Amohia 2023-06-29 21:16:52 UTC
(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?
Comment 17 Katrin Fischer 2023-06-30 18:08:44 UTC
(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.
Comment 18 Lucas Gass 2023-07-07 17:13:55 UTC
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.
Comment 19 Lucas Gass 2023-07-07 17:17:33 UTC
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.
Comment 20 Christopher Brannon 2023-07-07 17:46:50 UTC
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.
Comment 21 Katrin Fischer 2023-07-08 13:55:35 UTC
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.