Bug 20859 - Enter SMS number and SMS provider during self registration
Summary: Enter SMS number and SMS provider during self registration
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Lucas Gass (lukeg)
QA Contact: Marcel de Rooy
URL:
Keywords:
: 31107 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-06-01 22:20 UTC by Christopher Brannon
Modified: 2023-09-15 18:23 UTC (History)
7 users (show)

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


Attachments
Bug 20859: Add SMSalertnumber to OPAC registration page (4.57 KB, patch)
2023-05-25 14:43 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 20859: Add SMSalertnumber to OPAC registration page (7.86 KB, patch)
2023-06-13 22:37 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 20859: Add SMSalertnumber to OPAC registration page (7.93 KB, patch)
2023-06-15 15:24 UTC, Emily Lamancusa (emlam)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2018-06-01 22:20:28 UTC
Some libraries would prefer the option for patrons to choose their notification preferences and setup their SMS information during registration.
Comment 1 Lisette Scheer 2018-09-12 16:54:09 UTC
This would be great. 
Lisette
Comment 2 Katrin Fischer 2022-07-08 11:27:58 UTC
*** Bug 31107 has been marked as a duplicate of this bug. ***
Comment 3 David Cook 2022-07-11 01:02:08 UTC
I do like the sound of that. I might be adding a patch for providing the SMS alert number. Will see...
Comment 4 Lucas Gass (lukeg) 2023-04-25 16:45:45 UTC
If SMSnumber is added it would be nice to also add sms_provider_id.
Comment 5 Christopher Brannon 2023-04-25 18:13:33 UTC
(In reply to Lucas Gass from comment #4)
> If SMSnumber is added it would be nice to also add sms_provider_id.

Only if the particular type of SMS messaging requires it.  We use Twilio, that doesn't require this info.  Koha's built in SMS through email does.  I'm not sure about the iTiva (Talking Tech) setup.
Comment 6 Christopher Brannon 2023-04-25 18:15:05 UTC
That is, if iTiva has an SMS solution.  I think I am mixing that one up.  I know they do voice.  Anyway, not all SMS solutions require a vendor preference.
Comment 7 Katrin Fischer 2023-04-28 17:46:07 UTC
I guess it would always have to be configurable through the *Unwanted* preference like all other fields.
Comment 8 Lucas Gass (lukeg) 2023-05-25 14:43:39 UTC
Created attachment 151688 [details] [review]
Bug 20859: Add SMSalertnumber to OPAC registration page

This patch adds the SMS number field to patron self registration.

To test:
1. Apply patch.
2. Make sure an SMSSendDriver
3. Go to the OPAC self registration form.
4. Notice the SMS Number field now appears.
5. Use the PatronSelfRegistrationBorrowerMandatoryField and PatronSelfRegistrationBorrowerUnwantedField system preferences to ensure you can hide the field and make it required.
6. Self register while adding a SMS number. Make sure that when you view the newly self-registered patron that the SMS number is properly populated in the staff interface.
Comment 9 Lucas Gass (lukeg) 2023-05-25 14:45:11 UTC
I've submitted a patch that adds SMS number. Should we also add sms_provider_id here? 

What about messaging preferences? Should patrons be able to set those when self registering?
Comment 10 David Cook 2023-05-25 23:37:09 UTC
(In reply to Lucas Gass from comment #9)
> What about messaging preferences? Should patrons be able to set those when
> self registering?

That would be pretty cool
Comment 11 Lucas Gass (lukeg) 2023-06-13 22:37:31 UTC
Created attachment 152327 [details] [review]
Bug 20859: Add SMSalertnumber to OPAC registration page

This patch adds the SMS number field to patron self registration.

To test:
1. Apply patch.
2. Make sure an SMSSendDriver and some SMS cellular providers.
3. Go to the OPAC self registration form.
4. Notice the SMS Number and SMS provider fields now appear.
5. Use the PatronSelfRegistrationBorrowerMandatoryField and PatronSelfRegistrationBorrowerUnwantedField system preferences to ensure you can hide the fields and make them required.
6. Self register while adding a SMS number and SMS provider. Make sure that when you view the newly self-registered patron that the SMS number and SMS provider are properly populated in the staff interface.
Comment 12 Lucas Gass (lukeg) 2023-06-13 22:39:50 UTC
This patch adds SMS number and SMS provider to the self registration form. 

I filed Bug 34003 to add messaging preferences to the self registration form.
Comment 13 Emily Lamancusa (emlam) 2023-06-15 15:24:17 UTC
Created attachment 152386 [details] [review]
Bug 20859: Add SMSalertnumber to OPAC registration page

This patch adds the SMS number field to patron self registration.

To test:
1. Apply patch.
2. Make sure an SMSSendDriver and some SMS cellular providers.
3. Go to the OPAC self registration form.
4. Notice the SMS Number and SMS provider fields now appear.
5. Use the PatronSelfRegistrationBorrowerMandatoryField and PatronSelfRegistrationBorrowerUnwantedField system preferences to ensure you can hide the fields and make them required.
6. Self register while adding a SMS number and SMS provider. Make sure that when you view the newly self-registered patron that the SMS number and SMS provider are properly populated in the staff interface.

Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Comment 14 Marcel de Rooy 2023-09-08 09:17:03 UTC
Looking here
Comment 15 Marcel de Rooy 2023-09-08 09:28:15 UTC
+                    [% IF ( Koha.Preference('SMSSendDriver') ) && !hidden.defined('smsalertnumber') && !hidden.defined('sms_provider_id') && action != 'edit' %]

Please explain this condition.
What about the case that I want to hide one of them? Is that just nonsense?
Later on you test again:
[% UNLESS hidden.defined('smsalertnumber') %]
But you should know that already given the earlier condition.

Please clarify
Comment 16 Lucas Gass (lukeg) 2023-09-15 17:27:34 UTC
(In reply to Marcel de Rooy from comment #15)
> +                    [% IF ( Koha.Preference('SMSSendDriver') ) &&
> !hidden.defined('smsalertnumber') && !hidden.defined('sms_provider_id') &&
> action != 'edit' %]
> 
> Please explain this condition.
> What about the case that I want to hide one of them? Is that just nonsense?
> Later on you test again:
> [% UNLESS hidden.defined('smsalertnumber') %]
> But you should know that already given the earlier condition.
> 
> Please clarify

I suppose the question is should patrons be allowed to give a SMSnumber when SMSSendDriver is turned off?
Comment 17 Emily Lamancusa (emlam) 2023-09-15 18:07:29 UTC
I think the question is, why does the condition contain

&& !hidden.defined('smsalertnumber') && !hidden.defined('sms_provider_id')

# which will only show the section if both fields are enabled

instead of something like

&& ( !hidden.defined('smsalertnumber') || !hidden.defined('sms_provider_id') )

# which will show the section as long as at least one field is enabled

I hadn't looked that closely at the code when I signed off, but that's a good point - from what I understand, knowing the SMS provider of individual patrons isn't always needed, so a library may want to hide sms_provider_id but still show smsalertnumber.

There's no real use for knowing the provider without the number, though, so maybe the answer is to simplify the condition and only check whether smsalertnumber is hidden at that point.
Comment 18 Christopher Brannon 2023-09-15 18:23:24 UTC
(In reply to Lucas Gass from comment #16)
> (In reply to Marcel de Rooy from comment #15)
> > +                    [% IF ( Koha.Preference('SMSSendDriver') ) &&
> > !hidden.defined('smsalertnumber') && !hidden.defined('sms_provider_id') &&
> > action != 'edit' %]
> > 
> > Please explain this condition.
> > What about the case that I want to hide one of them? Is that just nonsense?
> > Later on you test again:
> > [% UNLESS hidden.defined('smsalertnumber') %]
> > But you should know that already given the earlier condition.
> > 
> > Please clarify
> 
> I suppose the question is should patrons be allowed to give a SMSnumber when
> SMSSendDriver is turned off?

If you want to make Koha take that into consideration for asking for it, you could.  Worst case scenario is that they take a number for SMS and nothing is done with it.  However, it seems, as a library, if I am going to ask for this piece of information, I would want to ensure that it is setup properly.  At the very least it is on the Admin if they ask for a piece of information they are not prepared to do anything with.  Does email work that way?