Email output could be much prettier
Moderators: Developer, Contributor
-
- Posts: 5
- Joined: 12 Mar 2019, 14:08
Re: Email output could be much prettier
@Cas I have created an account on your domain so we can discuss this further.
I'm trying to extend the templating side of things, but I'm struggling with a few things, mainly private bugnotes and bugnotes since status has changed.
Let me know if you're still working on this.
I'm trying to extend the templating side of things, but I'm struggling with a few things, mainly private bugnotes and bugnotes since status has changed.
Let me know if you're still working on this.
Re: Email output could be much prettier
@Kees, you did register but did not create an issue. In addition I send you an email but no resonse till now.
Re: Email output could be much prettier
So not sure where to report a bug for this new (awesome!) template system.
The notes being sent in email need to have any HTML escaped because they won't display, in Outlook at least, and that means that Outlook is open to someone putting nastiness in HTML code and then it will execute in the mail client. Maybe. (lol)
I'm not sure where to add the "escape function" code in the template system, nor would I feel confident finding every place that needed it.
The notes being sent in email need to have any HTML escaped because they won't display, in Outlook at least, and that means that Outlook is open to someone putting nastiness in HTML code and then it will execute in the mail client. Maybe. (lol)
I'm not sure where to add the "escape function" code in the template system, nor would I feel confident finding every place that needed it.
Re: Email output could be much prettier
@Mushu , i can add a function to escape the html. Must say that I received such emails in Outlook and it looked as designed. Which Outlook are you refering to? Can you add a rintscreen how you say the mail in Outlook?
Re: Email output could be much prettier
Outlook 2016 on Windows 10
The HTML entered in a ticket note was this:
And the email output in Outlook looks like this:
You can see in the screenshot that the message was scrolled all the way to the bottom so it's not being hidden by the fold.
:-)
The HTML entered in a ticket note was this:
Code: Select all
Example HTML output:
<meta property="og:image:alt" content="A shiny red apple with a bite taken out" />
:-)
Re: Email output could be much prettier
Attached the latest version of this modification.
It now supports 3 templates:
1. For new Issues
2. For updates of Issues
3. for notes
@mushu, I also made a change in order to escape the html as you requested. Please test this and let me know the results
It now supports 3 templates:
1. For new Issues
2. For updates of Issues
3. for notes
@mushu, I also made a change in order to escape the html as you requested. Please test this and let me know the results

- Attachments
-
- mailtemplate20220625.zip
- (24.81 KiB) Downloaded 631 times
Re: Email output could be much prettier
Thank you! We may not be using Mantis shortly, sadly, since I cannot get it to support OAuth because everything here has been moved to Azure and we no longer are allowed on-prem mailboxes. Since there appears to be a google OAuth plugin for Mantis I'm trying to see if they will allow us to forward the mail from Azure to a google mailbox, so that we can then connect like usual, but don't know if "they" will allow us to do that. Ugh.
Re: Email output could be much prettier
Well you can check if you can setup an auto-forward rule on your mailbox, then you know 

Re: Email output could be much prettier
Attached a new version of the mail template option.
Fixed some issues in the template engine and made escaping of the output configurable.
Fixed some issues in the template engine and made escaping of the output configurable.
- Attachments
-
- mailtemplate20220817.zip
- (26.13 KiB) Downloaded 295 times
Re: Email output could be much prettier
I just updated Mantis from v2.25.2 to v2.25.7 and using latest EmailReporting plugin (V0.11-DEV) but with the new Mantis version email isn't being processed. I've duplicated all of the code changes in the new files from the old ones, but mail_api.php is giving me a headache. Been working on it all day long and resorted to try/guess/test/try/guess/test....and getting sick of it. I don't know enough php to know how things work internally and Mantis isn't the easiest code to understand either. Now I'm stuck with this error:
But not sure where the problem is or how to begin debugging. It's possible I missed copying over some of the code but I've been over all of the files running diffs and think I got everything. Is the current version of templates compatible with the current version of mantis?
The log file shows this:
And that line of code in the template_api.php file is:
Any help or even guesses at this point are appreciated!
Code: Select all
Done checking all mailboxes
SYSTEM WARNING: 'Creating default object from empty value' in 'C:\MantisBT2257\c
ore\email_api.php' line 1333
The log file shows this:
Code: Select all
C:\MantisBT2257\core\template_api.php: 150: - - - - error_handler( <integer>8, <string>'Undefined variable: t_private', <string>'C:\\MantisBT2257\\core\\template_api.php', <integer>150, <array> { ['p_bugnote'] => <Object><BugnoteData> ( [id] => '11158', [bug_id] => 4487, [reporter_id] => 864, [note] => 'blahblah'...
Code: Select all
$variables['private'] = $t_private;
Re: Email output could be much prettier
NEVERMIND I figured out the problem. It was the recent fix for the Mantis memory leak when processing emails. They changed the code and I had to change it back to make everything work again. In /core/email_api.php is the following code:
I had to comment out their new $g_phpMailer = assignment and put back the original $t_mail = and then everything started processing mail again like magic! Since they had a memory leak for 15 years and it never affected me, I'm not going to worry about it now. Wasted a whole day on this, not happy...
Code: Select all
$t_log_msg = 'ERROR: Message could not be sent - ';
if( is_null( $g_phpMailer ) ) {
if( $t_mailer_method == PHPMAILER_METHOD_SMTP ) {
register_shutdown_function( 'email_smtp_close' );
}
//$g_phpMailer = new PHPMailer( true ); // orig
$t_mail = new PHPMailer( true ); // mine
// Set e-mail addresses validation pattern. The 'html5' setting is
// consistent with the regex defined in email_regex_simple().
PHPMailer::$validator = 'html5';
} else {
$t_mail = $g_phpMailer;
}
Re: Email output could be much prettier
@mushu sad to hear you wasted time, but his is not the first time that you got issues because of changed original source code of MantisBT.
Sorry to say, but I expect this will happen again and again, e.g. I just checked that 2.26.0 will also come with changes in email_api.php, so it might break your changes.
Please understand that we change internal source code whenever it's needed to fix a bug, to introduce new funcionality, to enhance existng functionality or to refactor code.
Sorry to say, but I expect this will happen again and again, e.g. I just checked that 2.26.0 will also come with changes in email_api.php, so it might break your changes.
Please understand that we change internal source code whenever it's needed to fix a bug, to introduce new funcionality, to enhance existng functionality or to refactor code.
Re: Email output could be much prettier
Not really mad per se, just frustrated. I'm not a php coder and don't have this kind of time to spend on things like this. Myself and the other developers really like Mantis and we understand the open-source concept and support it, but it's hard when we rely on a product and need to add functionality and every update causes this kind of effort to keep it working.
For example, the clock is ticking until a lot of people will be *forced* to stop using Mantis because it doesn't support OAuth for email. The world has moved to new authentication and Mantis is now behind the curve. I do understand the effort involved in adding that support, but I see no way you can not do it. I have a separate script that uses OAuth (dotNet c#) that externally parses our Azure mailbox to grab tickets for import into Mantis, then it calls the parser via the EmailReporting plugin in order to create new tickets and update existing ones.
The issues I have are to be able to support that plugin and to support the email template system from @cas. Using those pretty HTML templates for email to our customers seems like a no-brainer to me and the changes to implement that appear easy based on the little amount of code that cas wrote, and it would take very little effort to support that in the main Mantis code but so far that hasn't happened.
I have no idea what is on your upgrade/enmhancement list or how many full & part time programmers work on Mantis, but I'm hoping at least these two items are on that list. I will grit my teeth and dive into the code diffs between this version and the next one when that happens because the alternative is to switch to another ticketing system and I *really* don't want to do that.
For example, the clock is ticking until a lot of people will be *forced* to stop using Mantis because it doesn't support OAuth for email. The world has moved to new authentication and Mantis is now behind the curve. I do understand the effort involved in adding that support, but I see no way you can not do it. I have a separate script that uses OAuth (dotNet c#) that externally parses our Azure mailbox to grab tickets for import into Mantis, then it calls the parser via the EmailReporting plugin in order to create new tickets and update existing ones.
The issues I have are to be able to support that plugin and to support the email template system from @cas. Using those pretty HTML templates for email to our customers seems like a no-brainer to me and the changes to implement that appear easy based on the little amount of code that cas wrote, and it would take very little effort to support that in the main Mantis code but so far that hasn't happened.
I have no idea what is on your upgrade/enmhancement list or how many full & part time programmers work on Mantis, but I'm hoping at least these two items are on that list. I will grit my teeth and dive into the code diffs between this version and the next one when that happens because the alternative is to switch to another ticketing system and I *really* don't want to do that.