Bug 29365 - Koha::Email needs to be refactored
Summary: Koha::Email needs to be refactored
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 22343 26705 28729 29330
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-29 08:43 UTC by Marcel de Rooy
Modified: 2021-12-21 12:41 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2021-10-29 08:43:05 UTC
Follow-up bug for 28729
Comment 1 Marcel de Rooy 2021-11-01 10:35:01 UTC
Here are a few of my findings when working on bug 28729, 29330.

[1] We should move away from Email::Stuffer imo. We are wrapping a wrapper around a wrapper around Email::MIME. Just go there and use Koha::Email as your wrapper. Stuffer is too simple. We are already calling $message->email often enough to illustrate that point.

[2] Bug 28729 fixed an issue with Sender/Returnpath. We c/should solve this already in Koha::Email->create.

[3] Currently we call Stuffer::send_or_die and not send. We are only fixing stuff in the former one. We should do the same for send or let it explode.

[4] We are never passing from and to parameters to send_or_die only transport. Should we support them, or keep it in create only? Move the bcc handling to create?

[5] Attachments do not work. See bug 29330. We should refactor the code in Letters for that. Move it to Koha::Email? How do we save them in the database while they are pending?

[6] When doing these things, we can probably rearrange so that create can call Email::MIME at the end, and the result does not need further tweaking?