Migrate a google user/group member to an Alias

Owned by Andy Brook [Plugin People]
Last updated: Sept 11, 2024
3 min read

Scenario

You have a user that is being used as a mailbox for mail retrieval for Jira, that user may or may not be part of a google ‘group’ for notifications. Retrieval of mail requires a Message Source and related Mail Handler. This works but does not scale. This article explains how to the reduce physical mailbox count through use of Alias addresses. NOTE: o365 fails miserably to retain the actual Alias address a mail is sent to, so this article only applies to Google accounts.

JEMH 4.1.12+ contains the ability to use Project Mapping Domain Rule (addressee type) in place of Profile > Email > Catchemail, this was done to prevent the need for duplicate data entry. If all inbound addresses are covered through Domain Rule (addressee type) matches, the Catchemail section can be/should be empty.

Clear references to Mailbox acct

  1. Remove the user from any Groups that the mailbox user is referred in (make a note of the Groups)

  2. Remove the related account

  3. Decouple your incoming Mail Handler from the Mail Server, see Jira > System > Incoming Mail > Mail Handlers. Edit the handler referring the Mail Server account to migrate, switch the “Server” to “Local Files”, if you are using this actively, create a dedicated subfolder and refer that.

  4. Delete the now unreferenced Incoming Mail Server

Automation google account

  1. Create an automation account specifically for JEMH, ‘jemh.automation@nnn.com’

  2. Create an Alias on that account, that is the address cleared in the above, eg ‘itsupport@nnn.com’.

  3. Add the Alias address (type it in full, don’t pick the user as this would pick the user email not the Alias ). Additions can take a few mins to show up.

Setup Mail Server & Mail Handler

  1. Create a new Jira Incoming Mail Server for the main account ‘jemh.automation@nnn.com’, this will be the only account required. All mail delivered to this mailbox will be picked up each time the Mail Server checks, its much more efficient.

  2. Update the previously modified Mail Handler to refer the new Mail Source

At this point, everything is as it was, mail to ‘itsupport@nnn.com’ will be delivered through that Alias address into the ‘jemh.automation@nnn.com’ account, be picked up and driven through the related Mail Handler (and Profile). This profile will be common to all Aliases you may add in the future, meaning that you can handle n Aliases with 1 Mail Source and 1 Profile. Some further config in JEMH is now needed.

Setup Project Mappings

WeUse Project Mappings to route mail to specific projects (for create) based on Rules. JEMH Profiles have a ‘default’ Project Mapping, this has no rules, as it is where mail that does not match any Rule goes, to ensure all mail gets created as issues somewhere.

Setup a Default project that would be OK to collect any specific mail that wasn’t mapped.

Check “Subject IssueKey (comment) Regexps”

The Profile > Email > Pre-Processing > Subject IssueKey (comment) Regexps restricts what issue keys can be considered for commenting, which can be useful if you want to support a specific set of projects, but less so if you have hundreds of projects you just want to make work.

The default expression support a generic Jira issue key format:

\b[A-Z][A-Z_0-9]+-[0-9]+\b

If you have a restricted expression, eg for project NNN:

\bNNN-[0-9]+\b

The above will only work for that project, so you need to revert the more general form (or maintain a regexp matching ALL your projects, eg:

\b(NNN|MMM|OOO)-[0-9]+\b

Supporting Further Aliases

  1. Add a new Alias address to the ‘jemh.automation@nnn.com’ user in Google. This mail will then route through to the Default Project Mapping.

  2. To route such mail through an existing Project Mapping, just add another Domain Rule (addressee) for the Alias address

  3. To route such mail to a new Project, create a new Project Mapping and add a Domain Rule (addressee) for the Alias address.

Summary

By following this process you will end up with:

  • 1 physical mailbox with many Alias addresses

  • 1 incoming mail server defined in Jira

  • 1 Profile containing many Project Mappings

  • Your Jira instance will spend less CPU and IO time chattering with mailhosts and polling mailboxes with no mail