[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

Joonas Kylmälä <joonas.kylmala at helsinki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |joonas.kylmala at helsinki.fi

--- Comment #110 from Joonas Kylmälä <joonas.kylmala at helsinki.fi> ---
(In reply to Lari Taskula from comment #107)
> 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.

We use messaging preferences in the GUI so I would not switch to notice
preference.

I see these message preferences as their own object tied to a patron (not to a
patron's individual message). This would mean the name would be
Koha::Patron::MessagePreference and Koha::Patron::MessagePreferences. Then this
message preference is combination of a Attribute and Transports. 

Important thing to note, reading the code
C4::Members::Messaging::GetMessagingPreferences it appears that one
MessagePreference would correspond to one message_attribute. As far as I can
tell the table message_attributes is incorrectly named / created, the columns
should be in my opinion in the borrower_message_preferences table. So the final
structure could be 

Koha::Patron::MessagePreference             (contains both
borrower_message_preferences and message_attributes with JOIN)
Koha::Patron::MessagePreferences            (contains MessagePreference)
Koha::Patron::MessagePreference::Transport  (message_transports)
Koha::Patron::MessagePreference::Transports (contains all Transport of a
MessagePreference)

The message_transports seems to contains also unrelated columns to transport
types, namely the is_digest information which seems to be preference of the
patron instead of something that is decided based on the transportation medium.
But maybe you can fit this somehow nicely anyway? If it seems impossible we
could restructure first the messaging preference related tables.

Also see comment #80 from Jonathan, I think it the
$patron->messaging_preferences suggestion is a bit like what I have here but
instead with an object. Using object allows now modifying all the message
preference fields easily so I would go with the object.

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