I have tested this item ✅ successfully on a59506a

I followed the instructions, everything works fine.

I have tested this item ✅ successfully on a59506a

I followed the instructions, everything works fine.

I have tested this item ✅ successfully on a59506a

I have tested this successfully! Thanks @laoneo!

I have tested this item ✅ successfully on a59506a

I have tested this successfully! Thanks @laoneo!

RTC

RTC

I would question about the valid of this PR. Maybe someone with stronger OPP background should look at this more carefully

• You modified code to allow using MailerInterface but in the code of MailTemplate class, you have code to check for a concrete implement. Is MailerInterface incomplete ?
• In terms of features, although the intent is support MailerInterface, any implementation which is not Mail class will loose the functions provided by MailTemplate (because you hard code the check with a concrete implement before calling certain code):

• Loose the feature to use custom SMTP parameters for each mail template
• Lose the feature to handle attachments as string

All it does is to support the interface and doesn't restrict to the Mail class as we should work with interfaces. If you need these parameters like isHTML, then extend from Mail class. But there is no point to not work with interfaces. If I have a plugin which redirects everything to a custom Mailer service or whatever, there is no need to configure SMTP, etc. This brings a lot of flexibility while not loosing any settings from before.

I think it just a fake support to interface because if you pass any implement of the interface which is not a Mail instance, you will loose the features of MailTemplate which I mentioned earlier. Plus the support interface while having to check for concrete implement seems not right to me.

That's what I see from looking at the change in this PR. I will leave it to other maintainers and release managers to look at it further and make final decision.

Due all respect, but your comment doesn't make sense at all. This is how support for the interface should be implemented in a backwards compatible way. Mailer instances which come from the factory doesn't have to be always a Mail class. If a plugin would implement it's own mailer (which is not a Mail class) and set it in the global container, then this code would badly break. When this gets merged, then we can convert the rest of the code away from Factory::getMailer, otherwise we will have to life forever with it.

Sorry, I do not see the point of supporting interface causing loosing features of MailTemplate. I have expressed my concerns in my earlier comments, it's normal that you do not agree or I am wrong. Let's wait for feedbacks from others.

Sorry, I do not see the point of supporting interface if it causes loosing features of MailTemplate. I have expressed my concerns in my earlier comments, it's normal that you do not agree or I am wrong. Let's wait for feedbacks from others.

No problem, don't expect it either.

I would like to have two new tests - with Html tested.

I would like to have two new tests @exlemor , @CSGoat0 - with Html tested.

Back to pending. See previous comment.

Back to pending. See previous comment.

Please test attachments too.

I'v updated the testing instructions with HTML and attachment test.

We had some changes - @CSGoat0 , @exlemor could you test again - Thank you very much.

Hi @laoneo, Thanks for the PR.
This is the testing I've done but I am not sure about the conclusion.

Testing Results

Environment

• Localhost using Laragon
• Emails are received in folder: C:\laragon\bin\sendmail\output

Testing Instructions Performed

Test 1: Basic Mail Functionality

1. Logged in to the Joomla back end
2. Navigated to System → Global Configuration → Server tab
3. Sent a test mail

Result BEFORE PR: Mail is sent from only the main email (first user) to the sender who sent the test email (first or second user). The sender is constant (first user). Either it's first or second user who sent the mail, the sender is always the first user's email.

Result AFTER PR: Same behavior - mail is sent successfully.

Test 2: HTML Mail with Task Scheduler

1. Set HTML as mail format: System → Templates → Mail Templates → Options (top right)
2. Created a new user and enabled Receive System Emails
3. Created a GET request task:
   • URL: https://downloads.joomla.org/api/v1/latest/cms
   • Execution Rule: Manual execution
4. In the Advanced tab of the task form:
   • Notification → Task Success → Enable
   • Selected the respective user group from the previously created user
5. Saved the task
6. Clicked Run Task

Result BEFORE PR:

• The email is always sent FROM the main email (first user)
• The email is always sent TO the main email (first user)
• The configured user group (second user) receives NO email regardless who sent/create the task.

Result AFTER PR:

• Exactly the same behavior as BEFORE the PR
• No change observed

Additional Testing

• Triggered the task from the second user's backend (after recreating the task as the second user)
• Result: Still FROM the first user's email TO the first user's email
• The second user never receives any notification email regardless of who creates or triggers the task

Summary

Both the normal branch and this PR have the same functionalities. The task success notification always uses the first user who created the task as both sender and receiver, ignoring the configured user group in the notification settings.
I get this attachment in the email:

{"branches":[{"branch":"Joomla! 1.0","version":"1.0.15"},{"branch":"Joomla! 1.5","version":"1.5.26"},{"branch":"Joomla! 2.5","version":"2.5.28"},{"branch":"Joomla! 3","version":"3.10.12"},{"branch":"Joomla! 4","version":"4.4.14"},{"branch":"Joomla! 5","version":"5.4.5"},{"branch":"Joomla! 6","version":"6.1.0"}]}

Questions

Is this the expected output?

If this is the intended behavior for task success notifications (always going to the main user from the main user regardless of who sent/create it, not to configured user groups), then I will mark this test as successful as there are no regressions introduced by this PR.

Note: Receiver changes in the Test 1: Basic Mail Functionality

Could you please clarify?

Is the behavior the same as without the patch? If yes, then it looks like you probably found a bug.

Is the behavior the same as without the patch? If yes, then it looks like you probably found a bug.

It's the same behavior before and after the patch.
Mail system might be not accurate due to testing on local host. Maybe It needs a real host.

If it is the same as before the patch then it would be good if you can open an issue and mark your test as successful.

I have tested this item ✅ successfully on 6d52d72

Sorry for late reply, didn't notice the message.

I have tested this item ✅ successfully on 6d52d72

Sorry for late reply, didn't notice the message.

This pull request has conflicts, please resolve those before we can evaluate the pull request.

I have tested this item ✅ successfully on b180180

tested plain, html and html with attachments

I have tested this item ✅ successfully on b180180

tested plain, html and html with attachments