[Koha-bugs] [Bug 17499] Koha objects for messaging preferences

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17499

Lari Taskula <lari.taskula at hypernova.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |In Discussion

--- Comment #107 from Lari Taskula <lari.taskula at hypernova.fi> ---
There are some issues.

1. Considering class naming - These patches add
"Koha::Patron::Message::Preference::*", but to avoid confusion between
"message_queue" and "messages" table, would Koha::Notice::Preference better
match the purpose?

As far as I understand, message_queue and messaging preferences are related,
but "messages" is something different as it is only delivered in the web
browser in staff client and/or OPAC.

As of now:
- message_queue       = Koha::Notice::Messages
- messages            = Koha::Patron::Message
- message preferences = Koha::Patron::Message::Preference

Right now this class naming makes it seem as if these preferences have
something to do with "messages" when in fact it is only related to
"message_queue".

I believe the work on this Bug overlapped Bug 17959 so we ended up with this
confusion.

Still, notices vs messages is pretty confusing. It seems "Notice" is being used
for the messages that end up in message_queue. Since notices are related to
messaging preferences, should we call it notice preferences instead? I've
switched this Bug into "In Discussion" in order to solve this problem first.

2. There is some logic in C4/Reserves.pm, at the end of _koha_notify_reserve()
that should be centralized to avoid code duplication. In
C4::Reserves::_koha_notify_reserve() we have:
> next if (
>         ( $mtt eq 'email' and not $to_address ) # No email address
>      or ( $mtt eq 'sms'   and not $patron->smsalertnumber ) # No SMS number
>      or ( $mtt eq 'itiva' and C4::Context->preference('TalkingTechItivaPhoneNotification') ) # Notice is handled by TalkingTech_itiva_outbound.pl
>      or ( $mtt eq 'phone' and not $patron->phone ) # No phone number to call
> );

What this Bug currently adds is that messaging preferences can not be saved at
all if the above check fails. The reason behind this was from our production
experience - there were people constantly asking about undelivered notices even
when the mtt was selected. Bug 18595 together with this tackle the issue with
proper UI error messages.

I propose we centralize this logic into the preference class under a new method
"mtt_deliverable($mtt[, $borrowernumber])".

3. Current patches do not check if "phone" and "itiva" can be used as message
transport types. Those mtts are ignored here and in Bug 18595 altogether. I'll
work on it.

-- 
You are receiving this mail because:
You are watching all bug changes.