EmailReporting and different from addresses for different projects

[JQu]

Hi,

I configured EmailReporting plugin and it works like a charm. Almost

I got an issue while using it. I have multiple projects created. Each have notification emails enabled and individually configured "email_from" option. When user creates an issue, in a classic way, using web interface the notification email got correct sender email address. But when issue is created by EmailReporting plugin, notification email got wrong from address. It ignores project specific settings and gets value of $g_email_from option.

Am I doing something wrong? Or is it a bug?

[SL-Gundam]

First of. Its not really something which has been checked out since the inherent checking whether an incoming email is a note is not specific to a project. So would not have any purpose. Any incoming email, no matter the email mailbox that received it will be verified against all issues in the system.

Which version of EmailReporting are you running?
Which version of MantisBT are you running?

EmailReporting is using a project_override variable which allows it to access project specific variables during issue/note creation
It might be that that variable is ignored during the creation of the notification.

[JQu]

Now I use:
MantisBT ver. 2.12.0.
EMailReporting plugin ver 0.10.0.

earler I used:
MantisBT ver. 1.3.12.
EMailReporting plugin ver 0.10.0.

With the same effect. I was hoping that upgrade would help.

[SL-Gundam]

Alright I've made a modification that should, in theory, fix your issue.
https://github.com/mantisbt-plugins/Ema ... d4dd7f8d82

Keep in mind that MantisBT was never actually meant to support this. Because this will only work when MantisBT does not send emails using a cronjob

This change is part of a larger Experimental feature branch. So not really meant for production
If that bothers you, apply the earlier commit manually to your installation. Otherwise you can use the complete Experimental_EmailReplyParser branch

[JQu]

I changed this three lines in my copy of mail_api.php file. I tested it. Unfortunately nothing changes.

I did one test more.

I opened browser with two tabs. On first tab I logged in mantis and select project A. Then I called link mantis/plugin.php?page=EmailReporting/bug_report_mail on second tab. All notification mails, which was then generated, got address from project A settings. When I switched project to another (B) on first tab and then refreshed link on second tab all emails got address from project B. When I logged off from mantis all generated email always got global address.

[SL-Gundam]

Weird. It should have been enough...

I will see if i can find out what is causing this

On a side-note. Why do you want specific from address differentiation's? Like earlier mentioned. It's not necessary from the functioning of EmailReporting or MantisBT

[SL-Gundam]

Well i've been into the code and found out why this does not work as expected

When using the MantisBT web interface it's only possible to register one issue/note at a time. Therefore the project in question is registered the whole time during that time
EmailReporting on the other hand is capable of registering multiple issues/notes in a single run in any number of projects

project_override is only active while registering a single issue/note and reset after completion of that single issue/note

MantisBT triggers the sending of emails using a shutdown function which triggers at the end of script. So when EmailReporting is completely finished and has already reset the project_override
http://php.net/manual/en/function.regis ... nction.php

Now to get the behavior you want i would have to trigger a send for emails every time EmailReporting processes a single email.
I'm against making the necessary required changes since it could result in EmailReporting making multiple connections to a mail server in quick succession to send the email(s) and possibly trigger all kinds of spam protection mechanismes

But i will show you how you can fix this (not tested)
Before this line: https://github.com/mantisbt-plugins/Ema ... .php#L1118
Add

Code: Select all

email_send_all();

Keep in mind that you will have to re-add this line every time you update EmailReporting in the future

As I've yet to receive the reason you want this i feel that this modification is, in the end, useless. I advise you don't make the above modification but thats up to you

[JQu]

On a side-note. Why do you want specific from address differentiation's? Like earlier mentioned. It's not necessary from the functioning of EmailReporting or MantisBT

Let me explain.

I have several customers. For each of them i have separate project in MantisBT with unique email assigned. Each of my clients report issues by sending emails on one of dedicated email addresses. There is a need for the client to get confirmation that his issue was registered. At this point the client get confirmation email from global email address which is different from the one for which it was send. If the customer responds to this email, his message will be lost because will be delivered on wrong email address.

In next steps, when employee of our company add comment or change issue status, client gets notification from correct address. If customer wants to add comment to his issue simply responds to one of received emails.

The solution to my problem is to create separate MantisBT instances for each of our customers. But it will be uncomfortable to use for employees of our company.

[SL-Gundam]

Like i said, it's not necessary per project... but its one way to deal with it

See this EmailReporting wiki section: https://www.mantisbt.org/wiki/doku.php/ ... ion_emails

I would setup one main mailbox that EmailReporting monitores for replies. This email address will be used by MantisBT to send emails
Add more mailboxes as necessary and communicate these to your clients so that they can report new issues

[JQu]

Thank you very much!

Your solution works as expected. If you don't want to make it default behaviour maybe it can be an option which is off by default ? But it's your decision. I will not insist.

I found one more bug, a little bug. Next to the descriptions of configuration options are question marks. When I click on one of them page appears with message "This topic does not exist yet".

[SL-Gundam]

Thanks for letting us know

MantisBT moved the EmailReporting plugin page and as a result broke the help links.
We are in the process of correcting this

[SL-Gundam]

Has been corrected
https://github.com/mantisbt-plugins/Ema ... 523485c8d7

[Starbuck]

@SL-Gundam :

I dunno if we have a redirect plugin on the wiki but if that happens again, please let me know and I'll try to fix it. (I'm just starting to do some work on the wiki.)

What do you think about a hook at the bottom of function add_bug(), so that other plugins can add more custom processing beyond what you're doing there? Then this request to email_send_all() won't need to be re-added all the time - someone can handle the hook and call email_send_all or whatever else they need. I'm not sure how context would be handled, just tossing this out to see if it's worth considering.

Regards.

[SL-Gundam]

If possible please add the redirect on the wiki since older versions of EmailReporting do not have the new links
Old page: https://www.mantisbt.org/wiki/doku.php/ ... lreporting
New page: https://www.mantisbt.org/wiki/doku.php/ ... lreporting

EmailReporting will listen to MantisBT events so in this case the following events can be used

• EVENT_REPORT_BUG
• EVENT_BUGNOTE_ADD
• EVENT_UPDATE_BUG

[Starbuck]

If possible please add the redirect on the wiki since older versions of EmailReporting do not have the new links

Turns out my access is currently limited to the plugins namespace, so I can make changes to the live plugin pages, not the older ones. I'm trying to get that changed but let's not count on that happening anytime soon. Sorry bud.