Patrons messaging preferences endpoint RFC

This RFC should be the basis for bug 17505 and related bug reports that could need to be filed.

Actions and routes

The following table presents the current implementation, and the proposed changes.

Description	Action	Current path	Proposed path
List preferences for patron	GET		/patrons/{patron_id}/messaging_preferences
Overwrite preferences	PUT		/patrons/{patron_id}/messaging_preferences

Patron object definition

DB schema	Josef Moravec	tcohen
borrowernumber	patron_id	REMOVED
message_attribute_id	message_type [1]	message_attribute_id (I agree with the idea of a readable alias, but not really required)
days_in_advance	days_in_advance	days_in_advance
digest	digest	digest
borrower_message_preferences_id	patron_message_preferences_id
message_transport_type	transport_type [2]
system_preferences	messaging_preferences_status [3]

Notes

[1] Should by some kind of string identifier - maybe value from message_attributes.message_name
[2] list of defined transports from borrower_message_transport_preferences
[3] if don't enabled by syspref, get error 405 Method Not Allowed

Comments

Some thoughts:

• If we only support GET and PUT here, how will you deactivate message preferences? With an empty list of message types?
• What if there don't exist any entries for the patron in the tables yet - How will we receive the correct list of message types to update?

--Kfischer 08:12, 30 March 2018 (EDT)

In response to Katrin:

• We should add DELETE for disabling
• There should be a separate endpoint, with the list of options

--Tomas

Thinking about it, I think they should really be endpoints for each 'type', as in /patron/{patron_id}/messaging_preferences/{message_type},