Plan for MailLog 7.x-1.0 release

In general it's a developer module that cleanly works.

To release a clean version, we should put in a few more hours, even days for test coverage and UI improvements.
I'd be happy to see ppl joining development providing patches.

I'd be willing to throw a few hours at the D7 version. I have a client that needs this for quality control purposes.

That would be great. I'm changing this to the D7 release as this is our primary target.

Generally a good test coverage would help here.

The mail body should be unpacked with a mime decoding package if needed. I'm missing this a lot. Also you should view the mail body in a separate window... Real mime support is not that simple... Possibly we should only show the plaintext variant in the default output with additional links to additional mime parts. :-)

Features like cleanup (settings page button) also would help.

Also possibly exposed filters in the admin view, like an issue requested.

What i finally most miss is a helper tool (contrib module) that allows to split rendering and sending into multiple modules (e.g. Module mailsystem should implement this). Mailsystem should then allow to choose what mail plugin to encode (e.g. mimemail) and what mail plugin to send (e.g. smtp module). Maillog would then completely change its integration and act on a hook of that module. This requires some general redesign in contrib and an improved framework ... finally as a request for the next (D8) generation to make mails work cleanly next time...

Any other thoughts?

Hi miro_dietiker,

Summarizing:

1. Plaintext in the actual log entry view and then a click to open to see it encoded as per how it was sent.
2. Clear log feature
3. Admin page using drupal views w/exposed filter
4. Integration and/or being a submodule of the System Mail module.

First, is this an accurate summary?

Second, which items would you consider 1.0 releases and which would you consider 2.0? My vote is that items 1, 2, and 3 could be definites for a 1.0. But item #4 would take some time and I wouldn't want this module to stay in a stay of permanent dev status when it could be set as stable in somewhat short order.

Thoughts?

Generally great.

#4 is the most key factor but needs refactoring... So if someone starts to work on this, i would include it.
If not within next few weeks (till 1..3 is completed), we'll drop it for stable.

#4 We won't ever be a submodule of mailsystem. We just should integrate sutch interfaces if available.

Hey miro_dietiker,

One issue/conflict I'm seeing right now with the mailsystem module is that it appears to force one into and either/or situation with respect to mail logging. But what if one wants to log all mail in addition to sending out via the default or testing systems?

I think this is how I have it setup on a D6 installation without mailsystem and it works great.

BTW, i'm not ignoring our conversation here and would still like to proceed with getting a stable release out. I'm still buttoning up some client work.

@rickmanelius

Right ...

We could easily check for mailsystem and implement both modes.
Generally drupal core provides us an ugly state and mailsystem is still incomplete yet in what it should provide to be fully fledged. As long as this remains, we won't be able to build a perfect solution.

My priority is:
- First do it clean with core, not too much workarounds...
- Recommend use of mailsystem and implement a cleaner pattern if mailsystem is present.
(However the second solution might need another round of mailsystem improvements... I'm not sure about the current state.)

Sorry for being AWOL. I have a few ubercart features to take care of and then gotta loop back to this for my client. I'll try to dedicate 2 days to this and get as much done as I can contribute.

Perhaps their is a simple work around with the mailsystem module. For example, in maillog.mail.inc

line 6:
class MaillogMailSystem implements MailSystemInterface

lines 92-95:
if (variable_get('maillog_send', TRUE)) {
$default = new DefaultMailSystem();
$result = $default->mail($message);
}

Now a user going to /admin/config/system/mailsystem is faced with two options. If they leave the site-wide "default MailSystemInterface" as DefaultMailSystem, then MaillogMailSystem is never called and the features in /admin/config/development/maillog (e.g. allow emails to be sent, log emails, and display emails to developers) are never reached.

However, one COULD set "default MailSystemInterface" to MaillogMailSystem, but then in lines 92-95... you will lose all the customizations of defining a different system per class.

What if we adjusted and/or injected some code in lines 92-95 to grab the customized interface per class data and only use the DefaultMailSystem() if none are found. That way maillog can still access and do the logging and yet all the emails are still going to be sent out as per their specific customized classes.

Thoughts?

After further investigation, I believe the only clean way to get logging of live emails while still respecting (and storing) other classes in the mail system is to do all the logging through hook_mail_alter() by setting the maillog module weight to the heaviest possible setting so it runs dead last before the final formatting and sending. Here is my rationale:

drupal_mail's last two major operations are to format the message and send it off. To do that properly and respect the different mail class settings in the mail_system variable, the $message variable needs to retain it's key and module settings all the way through this operation.

So the only way to branch and/or save this message is to divert a copy of the pre-send $message at the last possible moment. In mail.inc, this occurs right at hook_mail_alter(). And if maillog was set to run last, it would have all the $message alterations as if it was actually sent.

In maillog_mail_alter, one could log every variable required to recreate the exact message (including the class used, etc). This would provide the feature 1 in comment #4 above. It would also allow us to avoid needing item 4 in comment #4 as the system would allow the individual mail classes AND it can still retain largely the same functionality if someone manually set maillog as the class for the various options in admin/config/system/mailsystem.

That would leave us with the clear log feature (2 in #4) and the views (probably will take some more thinking). That would help avoid a major refactoring and get a stable release out before any major changes in a 2.0 version.

Thoughts?

I tried Maillog 7.1, but it logged nothing -- because I used DefaultMailSystem?

Incidentally, Mail Logger worked out of the box.

Would be good to see this!

rickmanelius: "and get a stable release out before any major changes in a 2.0 version."
Given the nearness of D8 and the fact that we will work on a similar feature (possibly in context of past module), you can expect there won't be a 2.x ever.

A stable release will follow once we have something that is considered final for D7 with possible bugfixes or features that preserve API stability. So let's focus on making the fundament rock solid and tackle the related issues ASAP.

For discussions about details, please update the issues directly and (in case you relate to them) link them here. Feel free to update the severity (such as major) for release blockers.

Making the fundamentals rock solid sounds good to me.

I've released 1.0-rc1: https://www.drupal.org/project/maillog/releases/7.x-1.0-rc1

All we need now is some documentation and I think we'll be good for 1.0.

It appears that Maillog is not recording Ubercart emails (sent by Rules). Is this correct? Or is there a way to have those emails show up in Maillog as well?

@hockey2112: Please open a new issue for that.

Done: https://www.drupal.org/project/maillog/issues/3211512