...
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 | ||||||
|---|---|---|---|---|---|---|
|
Migration Tasks
This section provides some advice for migrating from DC to Cloud.
A close replication of processing in DC can be achieved in Cloud but may not be identical (we do have a goal for functional equivalence, but there are different challenges in cloud. Customers should expect differences as part of this migration. We will happily take feedback through support for missing features, but cannot commit to implementing anything.
Documentation
We have structured App documentationfollowing the layout in the app, providing background on those features.
There is a Getting started guide, follow it to gain familiarity over round trip configuration requirements.
We have a large amount of How-to articles docs, we don’t expect you to dig for everything, ask us in support for guidance if keyword search doesn’t yield results!
Licensing
Customers and migrators should be aware of JEMHC App licensing , about How plan consumption is calculated and what happens when Capacity Plan Fully Consumed, and if required How to reduce MSG / Data volume.
Integration with Jira
JEMHC exists outside Jira, there is no ‘mail handler’ to pick as there was in DC. Configure JEMHC standalone via Apps from the main Jira toolbar.
Mailboxes
As JEMHC runs externally, customers must configure their own managed mailboxes in JEMHC (eg Gmail, o365, etc).
Common Questions
Can customers user their nnn.atlassian.net mailbox in JEMHC
No. Atlassian do not support 3rd party use, and we don’t support Atlassian mailboxes for that reason, never mind Atlassian will frequently rotate the creds involved.
Postfunctions
These are a functional redo at the workflow level, see Workflow Post Function Notifications
Adhoc notifications
These are a functional redo. Cloud apps have an app-permission that needs to be granted in the Project Permission scheme to Use Ad hoc notifications.
System Notifications
See JEMHC > Licensing > System Notifications, there you can setup recipients who will be notified of system availability and usage.
| Info |
|---|
Outbound SMTP Connection It is a requirement for you to create a default outbound SMTP connector, regardless of whether issue notifications are expected to be sent. Be assured, no issue notifications will occur unless explicitly configured within JEMHC. If no such outbound is defined, any mail ‘not processed’ cannot be signalled via a “Forward mail” and so, the inbound queue will permanently block until manually solved. |
Notifications
See Getting started, it takes you through a fully functional bi-directional configuration, and links you to what you will need to learn in order to make any template customisations, specifically:
how to convert Webhook Events into a Preview Context for edit-time preview of notification Template Sets.