Some libraries would prefer the option for patrons to choose their notification preferences and setup their SMS information during registration.
This would be great. Lisette
*** Bug 31107 has been marked as a duplicate of this bug. ***
I do like the sound of that. I might be adding a patch for providing the SMS alert number. Will see...
If SMSnumber is added it would be nice to also add sms_provider_id.
(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.
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.
I guess it would always have to be configurable through the *Unwanted* preference like all other fields.
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.
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?
(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
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.
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.
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>
Looking here
+ [% 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
(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?
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.
(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?