Bug 38747

Summary: Have consistent signature in sample notices
Product: Koha Reporter: Caroline Cyr La Rose <caroline.cyr-la-rose>
Component: NoticesAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: alexander.wagner, philip.orr
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Caroline Cyr La Rose 2024-12-18 19:47:24 UTC
We currently have a plethora of signature styles across sample notices. It would be nice to make them consistent. Here are the ones I found in the sample_notices.yaml file (I skipped the slips and sms messages)

Notices meant for patrons

- branchname Staff (ODUE)

- Kind regards<br>branchname (BOOKING_CANCELLATION, BOOKING_MODIFICATION, BOOKING_CONFIRMATION)

- Kind regards<br>full branch address (ILL_PICKUP_READY, ILL_REQUEST_UNAVAIL, ILL_REQUEST_UPDATE, ILL_PICKUP_READY, ILL_REQUEST_UNAVAIL)

- Thank you (TICKET_ACKNOWLEDGE, TICKET_RESOLVE, TRANSFER_OWNERSHIP)

- Thank you,<br>branchname (ACCEPTED, AVAILABLE, ORDERED, REJECTED)

- Thank you,<br>Librarian<br>branchname (MEMBERSHIP_EXPIRY)

- Thank you,<br>Your library,<br>branchname (MEMBERSHIP_RENEWED)

- Thank you. (CHECKIN, DUEDGST, PREDUEDGST, PASSWORD_RESET,STAFF_PASSWORD_RESET)

- Thank you.<br>Your library. (SHARE_ACCEPT, SHARE_INVITE)

- Thank you! (AR_COMPLETED, AR_PENDING, AR_REQUESTED, AR_PROCESSING, HOLDDGST, RETURN_RECALLED_ITEM, PICKUP_RECALLED_ITEM, HOLDPLACED_PATRON)

- Thank you for visiting branchname. (CHECKOUT, RENEWAL)

- Your library. (ACQ_NOTIF_ON_RECEIV, PASSWORD_CHANGE)

- Your library (AR_CANCELED, 2FA_DISABLE)

- No signature (ACCOUNT_PAYMENT, ACCOUNT_WRITEOFF, DUE, PREDUE, DISCHARGE,OPAC_REG_VERIFY, WELCOME, 2FA_OTP_TOKEN, CANCEL_HOLD_ON_LOST, HOLD, HOLD_REMINDER, NEW_CURBSIDE_PICKUP, SERIAL_ALERT, AUTO_RENEWALS, AUTO_RENEWALS_DGST, LIST, CART)


Notices meant for staff, other libraries, vendors, etc.

- Thank you (TICKET_ACKNOWLEDGE, TICKET_RESOLVE)

- Thank you,<br>branchname (ACQORDER, TO_PROCESS, NOTIFY_MANAGER)

- Kind regards<br>full branch adress (ILL_PARTNER_REQ)

- Your library (2FA_DISABLE)

- No signature (TICKET_ASSIGNED, TICKET_NOTIFY, CHECKOUT_NOTE, ACQCLAIM, ILL_REQUEST_CANCEL, ILL_REQUEST_MODIFIED, ILL_REQUEST_CANCEL, ILL_REQUEST_MODIFIED, HOLDPLACED, HOLD_CHANGED, NEW_SUGGESTION, PROBLEM_REPORT, OPAC_REG, OAI_HARVEST_REPORT)


Is there any that would fit all of them? 

I like "Thank you,<br>branchname" provided the branch is available for the notice.
Comment 1 Philip Orr 2024-12-19 15:53:11 UTC
For sample notices (and for easier translation :) )
it might be good to have it as simple as possible.
So not the full address.
I like "Thank you,<br>branchname" as well.
Or "Kind regards,<br>branchname", I would prefer either of them.
Comment 2 Katrin Fischer 2024-12-19 21:12:23 UTC
Could we re-use the address includes we use in other spots for the signature? This way we could also pull the different formats according to the AddressFormat system preference (I18N).
Comment 3 Alexander Wagner 2024-12-20 08:14:11 UTC
Similar to Katrin I'd also vote for the possibility to move the signature to a separate file and include it somehow, not only for the samples but also for "real life". It's quite a number of notices where it should be added consistently, and it might be quite lengthy as well. This would also help in the translation issues Philip mentions: it's just one file that needs to be translated.

If it's possible to include a signature somehow right now did not notice that as I started out with the samples. So for me as a newbe they also serve as a "how they do it in Koha".

BTW: I'd also suggest to split off signatures from the mail body by the usual marker (`-- ` in it's own line). Including it in a file might also allow to enforce standard conformity by Koha adding it before the signature. (cf. RFC 3676, https://datatracker.ietf.org/doc/html/rfc3676#section-4.3)