microsoft/mail2bug

Questions about the ability to open different WITs

Opened this issue · 1 comments

Our plan is to use M2B as a gateway from ServiceNow to TFS. Depending on the issue in ServiceNow, I would like the ability to open different WIT types, if its a bug I want to open a BUG in TFS, if it's a change request, or a requirement, I want to open the corresponding WIT. I think I am interpreting the Sample config correctly, I'm guessing I would need a separate email address for each WIT type correct?

Taking that a step further, Let say for each project I have the 3 possible types. Do I need 3 email address for each project?

proj_a_bug@xxx.com
proj_a_cr@xxx.com
proj_a_req@xxx.com
proj_b_bug@xxx.com
proj_b_cr@xxx.com
proj_b_req@xxx.com

and just build all that into one big config file?

Thanks

Pat

That is the recommended way.
The other option is to use the EWSByFolder routing policy, and define rules on the server to move emails into specific subfolders, then you could reuse the same email address, though it has downsides:

  1. Because the use of server rules, you now have a "hidden" part of your configuration that is not part of the config file, which can be a bit annoying and harder - though not impossible - to back-up.
  2. EWSByFolder relies on defining rules on the exchange server, and the behavior of rules can get a bit finicky, especially if you end up with a lot of rules (this was actually the only option in the first version of M2B, and I added the Recipients option because there were too many problems with it)
  3. Your config file would still be just as big, the only thing you'll be reducing is the number of different email addresses

The main reason I didn't implement support for dynamically setting the WIT was that different types would usually have different defaults and/or mandatory fields, so just setting the WIT based on the contents of the email probably won't cut it, and you'd still need a config per work-item type, so the benefit of avoiding defining new email addresses was small.
If you do want to add that support, I'd suggest creating a new MailboxManager class or maybe augmenting the RecipientsMailboxManager to allow it to make the routing decision based on the title or contents of the email.