With the introduction of custom email messages in Bug 29393, we discussed (https://chat.koha-community.org/koha-community/pl/ixoy58im47dhpr4gmwtn9sdbjw) the opportunity to merge the "Patrons (custom slip)" notice type introduced in Bug 32986 and the new "Patrons (custom message)" notice type. We could also do away with the BOR_NOTES authorized value that is currently used for the non-email notes/messages and instead combine them into the above and use a checkbox for display options (staff or opac & email)
Is this a duplicate of Bug 36717 or a different thing?
What does the workflow look like here? As an example, right now we have a BOR_NOTE that puts a message on the patron card that they brought back an item missing a disc. So the staff person picks the note from the dropdown that says "Item mixup at <Branch>:" then they type in the title of the item. Would your suggestion keep that workflow, or would it behave differently? Also, presumably this would allow us to send an email at the same time, so we can let the patron know they need to get us the disc. Would it be the same note, or would different "transport types" (if that's the term for a staff note), generate different messages like notices do now (so we could send a more detailed message to the user)? My other concern is ensuring that no accidental emails are sent. I never want someone to accidentally click "email" on a message that should be staff only. The nice thing about the current setup is that it doesn't allow accidental OPAC notes.
We'd also need to consider what happens if the user doesn't have an email. I don't like the idea of rolling these into print notices.
(In reply to Caroline Cyr La Rose from comment #1) > Is this a duplicate of Bug 36717 or a different thing? Not a duplicate but a parallel.. The other one is about merging two 'message templates' into one template with two message transport types.. This one is about migrating the authorized value into notices so you get the additional functionality that notice templates offer (i.e access to template toolkit tooling with variable replacements and no longer a hidden hard coded limit of 200 characters).
(In reply to Benjamin Daeuber from comment #3) > We'd also need to consider what happens if the user doesn't have an email. I > don't like the idea of rolling these into print notices. This is just a proposal to get the discussion rolling. I don't have any sponsorship at this time to proceed with anything as yet. I think we can certainly ratify this area, perhaps introduce another transport type for 'display in browser' messaging or something along those lines.. Either way.. I don't want to reduce the functionality but rather clarify it.