I would like to be able to change the e-mail text that is being sent out can be customized and varied on different languages.

Would help with development.

CommentFileSizeAuthor
#17 694264-17.patch2.49 KBroderik
#16 support.email_.po1.79 KBIvan Simonov
#10 support-694264-3.patch826 bytesspan
#10 support_custom_email.zip3.16 KBspan
#4 support-694264-2.patch8.84 KBspan
#3 support-694264.patch9.53 KBspan

Comments

span’s picture

span commented
Version: 6.x-1.3-rc1 » 6.x-1.x-dev

This of course can be done atm by adding to the $conf array in settings.php but it would be a nice addition to be able to do this in the UI I think.

The way I would propose on doing this is to add a new tab/page to the settings area where e-mail text and information could be controlled. One could return the system_settings_form with the form as a parameter.

Since the information would be user submitted I suggest saving the content as variables to make implementation of language support easy.

If this would be implemented an update function would probably be needed for all those that have configured the $conf variable in settings.php. The function would save that data as the proper variables.

What are your thoughts on this?

jeremy’s picture

jeremy commented

A GUI would not be difficult to add to the existing functionality, it's simply not been a high priority for me. Patches are welcome, or it's bound to happen eventually....

span’s picture

span commented
Status: Active » Needs review
StatusFileSize
new support-694264.patch9.53 KB

I have added a new tab to the 'Settings' page where you are allowed to set 'Mail text settings'. It allows you to set subject and body for:
New ticket
New ticket comment
Account creation denied

It lists the available tokens in a DL. The descriptions might need some work but I'm not too sure on what they all do :P

The patch also implements the hook_locale() to make the e-mail texts translatable through the i18n search UI.

Another idea I have is to move the Mail settings from the 'General settings' and make a specific 'Mail settings' tab. What do you think?

This patch should be clean from whitespace. If it messes something up please let me know so I can try to find what's wrong. It looks good in the code for me so if something is wrong I assume it is my CVS client.

span’s picture

span commented
StatusFileSize
new support-694264-2.patch8.84 KB

Once again to keen on the trigger. Removed some unneccessary code in the admin file.

I'm thinking this features makes it so the else statement in _support_mail_text() which renders the mail is not needed anymore since there will always be an admin_setting.

eft’s picture

eft commented

Thanks for taking this on - I have similar motivation so will test your patch

jeremy’s picture

jeremy commented

There's a lot of code here. I'm wondering if it would be best to move this into its own add-on module?

I should also note that I'm considering the idea of completely implementing support notifications through Triggers and Actions, which would mean that the actual mail text would be defined in the Actions configuration section. If we go the route I just described, this add-on module will no longer be necessary. However, I'm not sure the Actions and Triggers interfaces are well suited for the notifications granularity required by the Support module.

span’s picture

span commented

I'm not at all familiar with Actions and Triggers so I can't really be of any assistance on how to set that up nor give any advice if it is suitable for handling this or not.

What I could do though is make this into an add-on module if you don't want it in the core. If you then decide that Actions and Triggers is a better place for this to be handled thats all fine for me :]

jeremy’s picture

jeremy commented
Status: Needs review » Needs work

Yes, I would like to see this turned into its own module.

span’s picture

span commented

I've started the process of moving this into it's own module and the admin parts are good to go but I'm stuck on a piece of functionality.

I've gotten stuck on how to override the functionality of _support_mail_text() where the e-mail is being generated. The way I worked out the patch was just to add another if statement to check if the i18nstrings module exists and if it did, load the text from a variable.

Do you have a good clean idea on how to make this happen in an add-on?

What I'm looking on doing right now is to use module_invoke_all() to cretae a hook for the add-on to hook into to set the $admin_setting variable.

span’s picture

span commented
Status: Needs work » Needs review
StatusFileSize
new support_custom_email.zip3.16 KB
new support-694264-3.patch826 bytes

Ok, I've implemented the module_invoke function to call the add-on to set the $admin_setting variable.

I'm attaching the patch for support.module for this small change.

I've moved all the functionality from patch 2 into it's own add-on and I've applied for a CVS account to host it.

I'm attaching it as a zip file for testing.

span’s picture

span commented

There is now a project page and a module which implements this feature. It can be found here:
http://drupal.org/project/support_custom_email

Please note that the module is still in Alpha1 and you will need the patch from #10 in order for it to work.

Anandyrh’s picture

Anandyrh commented

Hi,

This is really great, it seems i am closer to what i was thinking of, can we also add role based emails to the same module? so that we can have email- template, for each roles. where we can theme emails to each role.

Please let me know your thoughts as well....

Thanks & Regards,
AnAnD

jeremy’s picture

jeremy commented
Status: Needs review » Needs work

I'm afraid I don't understand the need for your hook. All you need to do is to create a GUI that allows you to set a value for the appropriate variables, such as support_mail_ticket_new_body or support_mail_ticket_comment_new_body. Once you update those variables, they will be used by the support module to generate the mails. Find more details in the MAIL.txt documentation included with the module.

span’s picture

span commented

I define the hook to be able to get the mail texts in a translatable form. This is the implementation of the hook in the add-on:

/**
*	Implementation of Support module defined hook_custom_email()
*/
function support_custom_email_custom_email($admin_setting, $key, $langcode) {
	if (module_exists('i18nstrings')) {
   	$admin_setting = tt('support_custom_email:mail_settings:support_mail_'. $key, $admin_setting, $langcode);
	}
	return $admin_setting;
}

The tt() function makes sure everything is translated in a multilingual site where the e-mail that are being sent out are in different languages. I can't really think of any other way to do this except for moving the tt function and the multi-language support into the Support module itself. I am however still a novice in module development so if you have any suggestions on a better way to accomplish this please let me know and I will try to implement it.

Another reason for the hook is that I have plans for the "support_custom_email" module to allow users to create different emails for different Clients which would then have to use the database to fetch the correct content. I figured a hook in the Support module would be a clean way to prepare for this.

span’s picture

span commented
Status: Needs work » Needs review
Ivan Simonov’s picture

Ivan Simonov commented
StatusFileSize
new support.email_.po1.79 KB

I just use a translation of email body. It works. Fully custom e-mail text :)
Check Attachment.

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented
StatusFileSize
new 694264-17.patch2.49 KB

@Ivan Simonov: that's great. And I hope your text found its way to a translation project.
But it does not cover custom e-mail texts in English. We want to have both (at least I do): I want to modify the English text (using an admin/settings screen, preferably), but also be able to send out that modified text in multiple languages.

@span/#14: I could not think of any way to do this either. But after a lot of digging, I found 'multilingual variables'. (http://drupal.org/node/564734)

And I think the ability to translate should be fixed in the support module itself, actually. I wrote a patch that does this, but uploaded it in a separate issue. See #981060: Introduce multilingual variables for mail texts. The 'real modification' to make stuff work with is also three lines, just like your patch - plus a new hook_init().

..... if that goes into the Support module, creating an admin screen is actually pretty easy.
Here's a patch against the Support module, creating an admin screen, which requires the patch from #981060.
Thanks to span; I took his code to build on. It is not complete yet (needs work to re-implement a list of tokens), but you can see how the 'multilingual variables' magic of i18n.module works:
- without i18n.module enabled, it does nothing special. It's just an admin/settings screen. If you customize the variables, they do not get translated, just like in the current support module.
- if you enable i18n.module, you will see notes under the text boxes saying "This is a multilingual variable", and:
- the contents of those text boxes will differ. It will show & store a different translated variable, depending on the presentation language of your page. (So if you have path prefixes enabled, you will edit different translations through yoursite.com/en/admin/support/settings/mail, oursite.com/se/admin/support/settings/mail, etc.)

Note: the above should probably be put into a README.

Note #2: It clashes with the Support Custom Email module, since it uses the same paths!
Actually, I'm sorry but I don't think there should be a separate Support Custom Email module, just for one admin screen, anyway. (If #981060 gets committed, the amount of needed code will be much smaller. Support Custom Email could still be useful for different per-client e-mail settings, as indicated in #14...)

If you want, set this to 'needs work' again and I'll redo the list of tokens on the settings screen... if/after #981060 gets committed.

span’s picture

span commented

Looks good to me.

jeremy’s picture

jeremy commented
Status: Needs review » Needs work

This seems to invoke a function that doesn't exist:

  $default_texts = _support_mail_text_default(NULL);

Where is _support_mail_text_default() defined?

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented
Status: Needs work » Needs review

In #981060: Introduce multilingual variables for mail texts.
This patch builds on top of #981060, as noted.

Me working further on this patch is not going to happen, without information about what is happening with #981060.

jeremy’s picture

jeremy commented
Status: Needs review » Fixed

Ah, thanks. I was only reading the patches, not the issue, whoops. ;)

This is great! It works in all my testing, and is something that was planned from day one. I made some minor changes to the text that is displayed to the end user, and made it translatable:
http://drupal.org/cvs?commit=502658

Thanks for your work on this!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.