Bug 14767 - Message delivery notes from SMS Gateway provider reports
Summary: Message delivery notes from SMS Gateway provider reports
Status: BLOCKED
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Lari Taskula
QA Contact: Testopia
URL:
Keywords:
Depends on: 14791 14843 14723
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-01 15:17 UTC by Lari Taskula
Modified: 2016-08-24 11:30 UTC (History)
1 user (show)

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


Attachments
Bug 14767: SMS delivery notes from SMS Gateway provider's report (17.76 KB, patch)
2015-09-17 14:08 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 14767: SMS delivery notes from SMS Gateway provider's report (18.26 KB, patch)
2015-09-18 10:20 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 14767: (follow-up) Use Unicode-parameter only when needed (7.14 KB, patch)
2015-09-23 13:36 UTC, Lari Taskula
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lari Taskula 2015-09-01 15:17:50 UTC
This feature is dependent on Bug 14723.

Since Bug 14723 introduces database a new column, 'delivery_note', we can now take better use of it if our SMS Gateway provider supports status reports.

Our local SMS Gateway provider sends us a HTTP request containing information about the status of delivery. If the delivery was failed, they will let us know the reason for failure. We should use the 'delivery_note' column for this data. I propose taking REST API way to accept reports from provider and change the status of messages accordingly in the database.
Comment 1 Lari Taskula 2015-09-09 13:36:51 UTC
A more detailed explanation for the reports and delivery notes.

Our SMS Gateway provider has a two-step delivery success response. When sending the HTTP request from our SMS::Send driver, our SMS Gateway provider will immediately respond if the message is placed for delivery OR the following error messages:
 - unknown error
 - invalid recipient (phone# syntax is invalid)
 - duplicate recipient (same phone# is given multiple times)
 - unallowed recipient (non-mobile/foreign phone#)

This is the first step to gather delivery notes from SMS Gateway provider. With Bug 14791 we are able to throw Exceptions from SMS::Send driver. I propose we throw an exception (e.g. Koha::Exception::SMSDeliveryFailure) with an accurate description of the error. The exception will be forwarded all the way to C4::Letters::_send_message_by_sms() where we can set the status of the message to 'failed' and add the delivery note accordingly.

However, if the initial request was successful and the provider has accepted it for delivery, we will move to the second phase of the delivery.

Second phase occurs after the delivery is complete on the provider's end. They will send us a request with appropriate information of the state of the delivery and an error message if the delivery was failed. For the second phase we should use REST API.
Comment 2 Lari Taskula 2015-09-17 14:08:17 UTC Comment hidden (obsolete)
Comment 3 Lari Taskula 2015-09-18 10:20:12 UTC
Created attachment 42695 [details] [review]
Bug 14767: SMS delivery notes from SMS Gateway provider's report
Comment 4 Lari Taskula 2015-09-23 13:36:29 UTC
Created attachment 42805 [details] [review]
Bug 14767: (follow-up) Use Unicode-parameter only when needed

This patch makes Labyrintti driver use Unicode parameter only when required.
In most cases in our local library we are fine with GSM 03.38. We will check
if data is lost when comparing the decoded gsm0338 encoded message to the
original message. Add it as optional feature in koha-conf - smsProviders -
labyrintti - Unicode. To turn it on, set the value to "yes".

For statistics, store the result in "metadata" field of message_queue
if the message was sent as UTF-16.

We also make a small fix to the response protocol since it is not in sync with
what Labyrintti expects. Their delivery report wants a 200 OK response, not 201
or 204.
Comment 5 Lari Taskula 2016-08-24 11:30:09 UTC
Blocked by Bug 14723.