...
Introduction
This article is for customers users of Enterprise Message Handler for Jira, who are considering migrating from JEMH for Jira Server/Data Center to JEMH Cloud, also known as JEMHCa self-hosted deployment to the cloud-based offering of the app.
Migration assistance
There is currently no automated migration tool, primarily due to differences in the data structure used for storing configuration. You will need to do ground up configuration of JEMHC.
In progress
We have been adding some configuration section-exports in JEMH, (e.g. image blacklisting) but as yet have not added the import aspect to JEMHC.
Things to consider
JEMH Server/DC is managed by you, the volume of email and the MB data volume that they comprise is down to your infrastructure to handle. In JEMHC, our infrastructure handles everything, in order to avoid becoming swamped, your JEMHC Subscription drives an allocation of a Capacity Plan based on the number of subscribed users, as your users increase, so does message volume and data capacity.
...
Cloud capacity plans
Your JEMHC subscription drives an allocation (1st of every month) of a Capacity Plan based on the number of subscribed (active) users; as your users increase, so does message volume and data capacity. If you consume the allocated plan, inbound mail and outbound notifications stop. No data is lost, it just remains queued.
New evaluators are initially placed on a limited capacity Starter Plan. We do this to help you fail fast e.g. where you start consuming all mail within a mailbox from long long ago.
If you consume your limited Starter Plan during eval, we can increase toward the plan level that your active users would give. You can request increases toward the level that your active users would allocate can be requested through support@thepluginpeople.com , should you exceed that, you would typically need to get a DataPack (see next).
Common setup problems
No Profile > Catchemail match with mail recipients
When you setup a Profile, the ‘catchemail’ address needs to match an address of incoming mail, so that JEMHC can know its supposed to process the mail, and so that addressee can be specifically excluded from storage (to avoid a mail loop). If you use a test mailbox, likely it will just not match.
Processing mail from beginning of time
When you setup a new inbound mailbox, do clear out the mailbox and/or set the mailbox to return mail ‘from this point forward’, not doing so may lead to ALL mail ever being processed (again) causing confusion (and Plan consumption leading to exhaustion).
Lack of a default SMTP server configuration
If you do not configure an outbound SMTP server, JEMHC cannot communicate to you when your inbound processing encounters a problem like the Profile > Catchemail list doesn’t match any mail addressees, to avoid data loss, the mail is not READ, to avoid repeat reading (and consumption of your plan) the inbound mail handler is taken OFFLINE. You really need a default SMTP server configured, its not used for issue related notifications without further specific configuration.
Getting more message volume and data
Regardless of cause, if you consume your plan then JEMHC will stop processing mail, more capacity can be purchased through Data Packs as needed, for through a 12 month term Plan Upgrade.
Typical cases are where you can be impacted are where you have relatively low-users and relatively high message volume/data. JEMHC has options:
Data Packs & Plan Upgrades
Data Packs provide an on-demand short term Message and Data volume increase. Plan Upgrades provide a 1y term to gain higher capacities normally attributed to a higher number of users on a monthly basis. Both Data Packs and Plan Upgrades are purchased out of band from Atlassian Marketplace as it has not yet matured to support such app-specific metrics (see Licensing App licensing for details).
Limiting message volume usage
Related to message volume, JEMHC delivers its notification by BCC to limit the numbers of mails JEMHC needs to send through your mail server. Switching this to TO will increase message volume.
Related to message data, JEMHC does support inline images in outbound notifications, and attachments, if you enable this, and make regular use, it can impact your data usage.
...
Mail servers
JEMHC cannot can’t use the built-in mailbox address provided by Atlassian, so you must use an external one, when . When doing so you may need to refer allow connections from the JEMHC public IP address to allow contact to your instance - this allows anyone on JEMHC to attempt this, for finer grained security, you would need to to your mail service. For finer grained access control, you could setup dedicated certificates that only your configuration has.
Microsoft office 365 (in:POP/IMAP/EWS, out: SMTP)
Gmail (in: POP/IMAP, out: SMTP)
Your own dedicated Exchange (in:POP/IMAP/EWS, out: SMTP)
New users start on a Starter Plan that is deliberately limited in capacity, this is to fail fast when problem scenarios occur (e.g. processing a POP mailbox where the ‘from now’ checkbox wasn’t set…)
What's missing?
Whilst there are many subtle differences between JEMH and JEMHC, given JEMHC is an entirely different implementation, the main functionality missing in JEMHC is Scripting support, which means there there is no Script Field Processor or Script Rules yet. This is a big feature to do for cloud and is something we hope to look at this year.
What's different?
Data Storage
Inbound mail flow
...
What's different?
Data Storage
As of MAR 2024 we support a default region of US as well as secondary DE region that new installation can pin their data to. As yet we do not have migration support from/to US deployment, potentially some areas can be manually exported (Profile JSON, templates etc) for reintroduction manually in a new DE deployment.
Inbound mail processing
JEMHC periodically retrieves mail from your configured mail servers over SSL for common protocols (POP/IMAP/EWSGraph). By default, JEMHC currently retains stores a very limited rolling window of the last 100 latest mails in full (for mail under 10MB), encrypted (at rest) in our database, residing in the AWS Virginia data center. We do this as part of auditing to allow failed mails to be retried. . This data is stored in either AWS region us-east-1 (USA) or us-central-1 (DE) and is encrypted at-rest and in-transit. Users can opt out of this (requires support interaction email retention, but requires you to contact us to re-enable), doing this would impact our ability to support you with processing problems.JEMHC communicates with your Jira instance over SSL transport security.
Part of Auditing > Inbound Messages will retain recipient info, including the Project/Issue Key.
We have no access to your mail held here. You have the option to ‘flag’ mail for support, at which point we are able to see/download that mail and the processing report through our back office support tool, accessed by employees only.
Outbound
...
notifications
| Info |
|---|
...
For background, see How Jira events turn into emails and Manipulate |
...
...
Your Jira Cloud instance will send event data to JEMHC when changes are made to issues. JEMHC will only retain webhooks for processing where you have configured JEMHC to generate notifications for specific projects, in this way, we retain only the subset required for JEMHC to do what you have configured.
...
When JEMHC sends mail, we again retain the most recent 100 messages (and their HTML payload) in Auditing > Outbound Messages , where we track the project/issue source, the sent email subject (typically issue summary) as well as the recipients. A ‘Report’ for the actual sending of the mail is also stored, including recipients, filenames of attachments added etc.
About PII
JEMHC communicates with your Jira instance over SSL transport security.
Whilst JEMHC only retains the most recent 100 webhooks and inbound/outbound mails, we retain the last months worth of ‘audit’ records that something happened, meaning, webhooks, inbound mail and outbound mail. If a user choose to ‘be forgotten’ Atlassian will notify JEMHC and removals of related records will occur.
...
For inbound, Jira project metadata defining fields that we need to populate. For outbound, we retrieve any data within the typical REST response for the issue, eg e.g. /rest/api/latest/issue/ABC-123. In addition, attachment data referred (eg e.g. inlined screenshots, but could also be any attached file, if you configure JEMHC to do so!), icons for projects, issue types, priorities, all the things you’d you'd expect in a Jira email.
Is it data in transit or data at rest?
...
JEMHC data is currently stored in a highly available dedicated JEMHC database, which is not publicly accessible.
Data Residency
...
| Info |
|---|
Background information: https://www.atlassian.com/software/data-residency , non US realms: https://www.atlassian.com/roadmap/cloud?category=dataManagement& |
JEMHC currently only has one ‘Realm’, located in the USA, we expect to look into JEMHC data residency later in the year..
Profiles
JEMH Server/DC Profile exports are not currently compatible with JEMH Cloud.
The structure of the JEMH Profile is very different from JEMHC. JEMH Profiles still have a lot of top-level configuration whereas JEMHC was designed with lessons-learned from JEMH whereby Project Mappings in JEMHC are Profile top-level feature, containing the majority of all configuration, Rules also then provide a subset of the Project Mappings.
Scripting support
Scripting support in JEMHC exists for:
Javascript PreProc Task (header manipulation)
Javascript Script Field Processor
Javascript Script Rule support in Project Mappings
Javascript Custom Field Default
The multi-tennant nature means that security is always at the forefront, and for that reason, scripts are restricted in what they can do, effectively they have access to the ‘issue' JSON structure, and the mail content where applicable, there are no remote calls allowed and no special custom functionality beyond javascript default scripting.
Messaging
Inbound/Outbound mail server connectivity isn’t within JEMH for Server/DC, in JEMHC, we have re-implemented all inbound/outbound mail server connectivity functionality. For example, JEMHC has OAuth authorization support, which requires specific admin actions to support, that cannot be migrated.
...
In JEMH Server/DC its possible to use regular expressions to match Project keys that should be handled through this particular Notification Mapping. In JEMHC, we avoid regular expressions and simplify things, enabling users to ‘pick’ all or nominated projects.
Transition Attachment Custom Field picker to allow
The Use the JEMH Transition Attachments Custom Field attachment picker for workflow transition screen has not yet been implemented in cloud, logged as:
JEMHC-3764
Status Notifications
This has not been implemented in cloud at this time.
...
We don’t support migrating audit history from JEMH Server/DC to JEMHC as JEMH Server is able to retain unlimited volumes of data. In JEMHC (with customer opt-out) we can store the most recent 100 inbound and outbound messages for your diagnostic purposes.
Issue Association
Foreign Key Issue Association configuration in JEMHC is different due to the structure of the Profile.
In short, JEMHC restricts Issue Association in a Project Mapping, scoping to the mappings selected Project.
However, the default Project Mapping will not scope to the mappings selected Project, but any non-default mappings added that inherit the Foreign Key Issue Association will scope to the non-default mappings selected Project.
For further information, see https://thepluginpeople.atlassian.net/wiki/spaces/JEMHC/pages/72908873/Understand+how+Issue+association+works#Regexp-foreign-key-association
Public REST API
JEMHC has yet to implement a public rest API as we have for DC (Use JEMH Public Rest API to Export, Import and Update profiles ). Whilst tilted as for Profiles, we also exposed a way to deliver Mail directly over REST, which was utilised by some 3rd party email client app integrations. Those integrations will need rework once we have a public API in JEMHC. We are tracking this feature interally as
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|