This feature is possible however it does come with 2 limitations:
1. Regardless of what the To: address is, the From: name/reply address will always be only one of the multiple addresses. For example, if you have firstname.lastname@example.org and email@example.com going into the same workspace, all emails that come from this workspace will have a from name/reply address of the first configured email address for the workspace (firstname.lastname@example.org in this document). It will not differentiate between the two to determine what to display.
2. Also, editing any of the modified mail accounts via the web interface will overwrite any of the changes made in this document. You will have to re-do the changes.
In the FootPrints Incoming Email Setup (Administration|System|Email|Configure Incoming Mail), add each address and select a workspace for each address.
Next, open the MRMultiIncoming file found in FootPrints/etc/. Use a text editor such as Wordpad or Notepad to edit the file. Each line represents a different email address entered in the system email page. Each piece of information is delimited by a colon ":" character. The second to last piece of data represents the workspace number. Change each line's workspace number to match with the workspace number that should receive all of
the emails. Save and close the file.
Depending on the type of email account used, different instructions apply.
If the email accounts are IMAP, then edit the imap.txt file in the FootPrints/etc/ directory. In this file, each field is delimited by 3 colon ":::" characters. The last value is the workspace number. Again, change each value to match the workspace number that will receive all the emails. Save and close the file.
If the email accounts are POP, then edit the mrpop_%username%%workspacenumber%.bat file found in the FootPrints/cgi directory. In my example, I want to point email@example.com address to the Service Desk workspace. The firstname.lastname@example.org address is currently pointing to workspace 18. Therefore, the mrpop file will be named mrpop_appsupport18.bat. In this file are 3 lines. Changes need to be made to the first and
third line. The first line has data delimited by 1 colon. The last field has the workspace number. Change that value to match the receiving workspace’s number (53 in my example). Do the same on the third line after the user name for the email account. This must be done for each pop account created.
Once the above steps are finished, each .bat file needs to be renamed to change the %workspacenumber% (ie the 18 in mrpop_appsupport18.bat). Change that number to match the receiving workspace’s number.
The appsupport address will now be pointing to the Service Desk workspace.
Please note: Editing any of the modified mail accounts via the web interface will overwrite any of the changes made in this document. You will have to re-do the changes.
The next steps are optional. The following steps allow FootPrints to auto-assign a team based on the “To:” email address. For example, emails to email@example.com will automatically assign tickets to the Application Support team in my Service Desk workspace.
Edit the MRlocalDefs file found in the FootPrints/cgi directory using Notepad or Wordpad. Add the following line after the $NT = "NT"; line:
$ASSIGN_INCOMING_BASED_ON_TO = 1;
Save and close the file.
Next, double-click the icon below and open the file in Wordpad.
Edit the file to match up each incoming email address to a team name in the workspace. Be sure to leave the quotes in place as they are in the file and type in the team name exactly as it exists in the workspace.
Save the file as AutoAssignIncomingEmail.yaml into the FootPrints/etc directory.
This procedure was:
Created by: Michael Santos
Last Updated: January 27, 2010
Last Updated by: Michael Santos
Thanks Jean Abou-Diwan for your answer it's very informative.
Just want to try my luck for this question,
Is there anybody tried a way to workaround the limitation 1 which the "From" address display accordingly?.
Thanks in advance.
I don't think it's possible, once it's created as a ticket, FootPrints can't send with a different FROM, from the same workspace....
You can manage this with multiple workspaces... but I always try to convince my customers to make a unique FROM because it's easier to manage. (and for incoming emails, I even manage this with some rules in outlook)
Jean is correct. I authored the document and without code changes, there will only be one FROM address/name.
Also, the PDF was originally a Word document that had the AutoAssignIncomingEmail.yaml file. It's not "clickable" in the PDF, so I'm attaching it here. You only need to use this and the MRlocalDefs variable if you wish to assign tickets to a team based on the address that the mail was sent to.
AutoAssignIncomingEmail.yaml 72 bytes
I'm quite interested in that...as I have a project that read from multiple emails (it always send from the same email) but they use the incoming email to assign to one team.
At the begining I solved that using rules in Notes (with notes script) that add a text in the subject and a rule that send that email to the email that footprints read...and escalations that read the subject and assign to the group... It was working like a charm and had a lot of accounts working in that way...then we changed to outlook 365 and no option to change the subject of the email (only with transportation rules but they are restricted and are "general" rules so they affect to performance....so I had to find a plan B...I'll create (today I've made my first) one workspace for every email account that will only read the ticket and move to the good workspace adding to the title the text...
That doesn't like to me as I will had to have X workspaces for nothing... so I'll try that (I belive I've made test with toying with the MRmultiincoming but had problems...mainly that sometimes the emails to that accounts where send in cc or in cco not in To: and that I didn't know how to assign then the tickets to the team that should work with it - and that you have given me the clue)
So thanks...I'll see if I can do something with all that information.
today I will expend time playing with that but I've a question...the AutoassingIncomingEmail.yaml what read is the real TO: or take into account from wich email it cames?
I'll try to explain...if I don't have one email configured in the "configure incoming email" in the multiway that you explain can I still use the yaml for that?... I'll try to use email rules to simulate the all emails going to a single project...
I have email A, B, C and the D is the one that the workspace has configured...
I create a rule that says that A, B and C all the emails go to D (as I've done that I know that the TO: keeps the original A, B or C) the email will be readed by FP in the email D and if the yaml work I can say if it cames "from" A assgin Team A...if the TO: is B assign Team B...
I'll see if I've a way to test that...
I really need to have this working and this post as opened the eyes to a new way to do it...hope it works !
I'm quite excited as it works...the only problem is that when I try to put more that one rule in the yaml (one for every to: email) it gives me an error... can you please tell me how will be done?
I'm doing in that way...but (for past experiences) I know that the yaml are a bit tricky with the spaces, enters...etc...
team: 'Team Vegas'
Can somebody tellme if it's right or how can it be done !
Sorry for kidnap the post but I really need that to work...it was a solution in the last minute !
Can you attach the yaml file to this thread? I'll then look at it for you.
Thanks for the offer !
At last I made it work (It was a matter to put an space before the team: and between the team: and the 'team' )...so I've made with 2 accounts and it seems to work...I'll try with more (only making test for now)...
I see that if they send to multiple TO's that won't work (only if the right one is the first) and that only works for To not for cc. I saw in and old numara post a "patch" to do that...but I see that is not official...
Do you know if you can put also the project: ? (I see in the the documentation of the old post but doesn't know if it was refering to the patcht they made or to the original issue the TO)
Thanks again for the offer
Sorry to resurect that treath !
Can it be assigned with the Yaml file to an agent instead of a team? how?
It only work for TO: not for CC: right?
I have to play with it again.. only the TO: assign...I've it working for an email but I have to add more and having problems with the yaml file... can anybody tell me how to do it for several accounts ?
What I've is that - the first one was working fine is after adding the second account that it keeps giving me errors in FP...
from: 'TUI Travel PLC A&D'
from: 'TUI Travel PLC A&D'
There's any way I can test that before putting in production and get an error? that is working in the 11 ? I'm not at 10 but hope to change to 11 soon and want that to work
EDIT: I've found it I had to ask to install the ysh to be able to do the cat file.yaml | ysh but it allowed me to see what was wrong (an space in the last empty line)
Here is the suggest format of the AutoAssignIncomingEmail.yaml file for this solution in Footprints Service Core 11.5 and 11.6.
Allan, and anyone else asking about how to control the Reply To: address and From: value used in notifications from the workspace that has multiple incoming mailboxes, see Antonio's post from May 15, 2013 and note how each entry in the .yaml file has a 'from' and 'reply' property. If an issue is assigned to the team matching the 'team' property of one of the yaml file entries, then the notification will use the 'from' and 'reply' value from that same entry.
To make all notifications from the workspace have the same from: and reply to:, you could add a line to MRlocalDefs
$ASSIGN_INCOMING_BASED_ON_TO_USE_DEFAULT_FROM = 1;
and then you don't have to define a 'from' and a 'reply' setting for each entry in the yaml file.