Misc Atlassian Connect / Platform Issues affecting JEMHC
The following are known issues and workarounds, for new issues, please log a support request at https://thepluginpeople.atlassian.net/browse/JEMHC
Atlassian Have done this, we need to automate the allocation,
- on Active License installation
- Start of every Month, for Active License installations
This keeps new users/evals on the Bronze1 Starter plan, possibly a good move to restrict 'accidental' mass-mailing...
We need to manually allocate Plans (based on users) as user count cannot currently be determined. New subscribers automatically get the lowest Bronze1 10 user plan.
Until this is resolved and we have integrated it, to get an appropriate plan set, tell us how many users you have via the Feedback UI button!
JEMHC cannot create or comment on issues 'as' a given user. Whilst Issues can be created and the 'reporter' attribute set to a given user, the actual issue is created by the "JEMHCloud Addon" user. The underlying problem becomes more visible when commenting, as there is no similar 'attribute' and the comment creator is the same Addon user.
This scenario is more visible to JSD registered users (that login).
Currently, JIRA users are attributed in comments made by the addon user, they are not set as the reporter - but if the workaround user is set, the reporter can be set too, however, this only works for issue creation, comments are still made by the Addon user.
JEMHC includes a header for issue creation and comment to indicate who the sender was. Its also a customizable bit of content that allows additional email related facts to be added (who else was on cc: for example)
The current release of JEMHC supports Act As User, in a limited capacity currently, such that Comments are created 'as' the user associated with the sender that we were able to lookup (requiring the workaround user setup). You'll need to have your addon descriptor up to date (Manage Addons / Update) and enable this within your Profile.
|Notification schemes are not usable remotely|https://ecosystem.atlassian.net/browse/ACJIRA-218
Awaiting implementation - see
Currently JEMHC implements a pseudo notification scheme, with some common JIRA notification entities, like Reporter, Assignee, Watchers and user picker custom fields.
|Users cannot be 'search for' by email address, through Atlassian Connect.||https://ecosystem.atlassian.net/browse/AC-1014||We have a workaround users, that bypasses Atlassian Connect by using a new set of user credentials that enable that user to do the lookup remotely.|
|Advanced workflow support|
|We'd like to be able to provide a nice Project Mapping section for workflow auto-advance with selects for From Status and required Transitions, but we cannot.|
|Updating JIRA Software Epic-Links (after issue was created)||https://jira.atlassian.com/browse/GHS-12506||Its only currently possible to set the Epic-Link during issue creation. Sprints may have a similar problem.|
|Inlining images hosted on Cloud storage||https://ecosystem.atlassian.net/browse/ACJIRA-15|
None. JIRA has no user macros, and certainly none that are possible via connect, tracked:
|Webhook traffic is lost if JEMHC is offline. JEMHC is a highly available service with self-healing capabilities but can be killed by a service provider network problem. The JEMHC upgrade process has zero downtime in th enormal case, specifically to address this point.||https://ecosystem.atlassian.net/browse/AC-2068||At this time, none.|
|We monitor JEMHC closely and sometimes notice problems we think you'd want to know about/fix. Our access to contact details is very limited, if the email addresses defined in JEMHC > Licensing > System Notifications : Email Addresses doesn't contain valid addresses (yours!) then likely our pro-active support requests will be unsuccessful. Atlassian Support cannot help either. Ideally as a vendor, we'd be able to flag things for your attention, see logged issue||https://ecosystem.atlassian.net/browse/AC-2073||None, if your contact emails and/or forward user address are old/invalid, ,then you'll be potentially missing out on failed processing notifications and more.|
|System images from JIRA may are not automatically blacklisted by hash||https://ecosystem.atlassian.net/browse/ACJIRA-1287||JEMHC normally loads all project and user avatars from JIRA @ thepluginpeople.atlassian.net, but has been unable to do so since JUN 2017. The only way to block such images is to use the global blacklisting feature to match all images less than a few KB.|
|Inline Images not shown in the new issue view|
"Importing attachments via CSV is adding broken attachments links for the new Jira issue view." (its apparently the same problem)
Historically, a description/comment that has a !image1.png! tag will show the attachment (image1.png) inlined in the text.
In the new issue view, the images added via Jira rest version 2 are broken. If the issue view is swapped back to the old view, the inline images are fine.
Installation and Licensing Issues
Addons reports Evaluation Expired after a few hours of installation
Sometimes, the Atlassian licensing system is offline, at such times, customer instances report 'Active' licenses, that cannot be differentiated from real ones. At some time later, Atlassian flips these Active licenses to Eval (https://ecosystem.atlassian.net/browse/UPM-5541), unfortunately, this then falls foul of JEMHC checks against license cycling (https://ecosystem.atlassian.net/browse/AMKT-12613) and currently results in customer lockout with an Expired Evaluation message. We will be making JEMHC more flexible to reduce friction in this area, enabling these transitions for a 24hour window from host install (
) which will address the majority of cases. Chances are that if this affects you, we haven't yet had a chance to flip you back to Evaluation status, it will happen, but feel free to ping us at email@example.com for a confirm.
This response is telling you the addon cannot talk to your instance to be made available. The reason for this us (so far) limited to two causes:
1) Uninstall/reinstall cycling that results in an evaluation exceeding "remainder of first month + 30days"
If you install JEMHC then perform an uninstall / reinstall cycle some time later, your eval period may be presented OK by Marketplace, but its a bug. JEMHC prevents re-installation of evaluations by default as this would potentially provide a vector for denial of service (re-installation resets security tokens). This restriction can be changed on request, please contact support@thepluginpeople referring your instance URL (e.g. xxxxx.atlassian.net)
2) You have restored your JIRACloud from a backup
Restoring a JIRACloud instance resets the information used by an Addon to authenticate with your JIRACloud, effectively breaking our ability to be 'trusted'. This information is stored on 'install' of the addon only. Unlicensing the addon and re-licensing will not solve this, you must unlicense, and uninstall the addon, then, a repeat installation will reset the required data.
This issue is tracked at https://ecosystem.atlassian.net/browse/AC-1528
JEMHC doesn't support repeat evaluations, as per Atlassian policy you get the remained of the current period plus one full month to evaluate JEMHC. If you do nothing, you'll roll on to a paid subscription and everything works. If you cancel, or go active for a time, and cancel, then reinstall the license, Marketplace will allow this and declare a new evaluation license is active, but JEMHC will not permit his, you must have an active paid subscription to use JEMHC requested via Atlassian Support.
It Doesn't Work
Unable to resolve users by email address
In order to JEMHC to perform actions "as" a user, it needs to be able to lookup that user. The requirement for this is that User email visibility is either visible or masked. If its hidden, no lookup will be possible and only email user support will be possible with JEMHC.
Blank screen when accessing JEMHC configuration
If local storage and third party cookies are disabled in your browser, JEMHC will fail to load it's configuration pages. JEMHC relies on local storage to store application data that is required to allow data to be shared between configuration pages. With local storage/third party cookies disabled you will see the following screen when attempting to load JEMHC:
There are two solutions to this problem, JEMHC must have access to local storage within the browser to allow the configuration pages to be loaded. In chrome you can enable local storage and third party cookies by browsing to Settings → Show Advanced Settings → Content Settings and ensuring that Block third-party cookies and site data is unchecked.
If you must block local storage and third party cookies for websites, you can optionally add an exception for the JEMHC domain by clicking Manage Exceptions and then adding an exception for the JEMHC add-on domain which is jemhcloud.thepluginpeople.com:
JEMHC Public IP Address /Firewall Issues?
Regarding access of the Configuration screeen, JEMHC has a https service listening via DNS: https://jemhcloud.thepluginpeople.com/app/ , that URL should return a JSON 'descriptor' for the application, if not, contact your network team to assist.
Regarding polling of Mailboxes, JEMHC has a public IP address for service interactions, it is 220.127.116.11, and should be allowed to connect to your network on the ports that you have configured.
Unable to load JEMHC Configuration screen - Adblock?
We have heard that Adblock can stop JEMHC from loading (blank screen scenario), confirm this by looking at your browser Developer Tools, if you see Status: blocked consider disabling Adblock for your JIRA:
|Adblock active indicator||Developer Tools blocked resource message|
No notifications for JIRA actors (Reporter/Assignee/Watchers etc) or Group members
When you have validate that your outbound SMTP connection is good (Messaging > Message Outbounds can send a test mail) and that you haven't hit a JEMHC plan limit (Licensing), a further possibility that blocks outbound notifications is if you have set:
- JIRA > System > General Configuration > User email visibility : HIDDEN
This causes email addresses to be removed from the REST response for a user lookup, meaning we cannot locate JIRA users email addresses and therefore cannot notify them. Use the MASKED option instead.
Logged as JRA-61565 (Closed : Wont Fix)
No Webhook events are being received (Auditing > Events)
JEMHC depends on Webhook Events sent from JIRACloud, there is an addon responsible for this, and if disabled, no events will be sent, so that means no notifications! Check this in your JIRA Manage Addons > , if you see it is disabled, enable it, or if you are unable to do so, log a support case at https://support.atlassian.com
Disabled Webhooks Plugin
External Storage is temporarily disabled. Please try again later
This message is shown in issues where JEMHC External Storage has been configured. It occurrs during times when uploads/downloads must be quiesced whilst JEMHC server nodes go through an upgrade. During the upgrade cycle Webhook events continue to be captured and stored in the database but inbound mail retrieval and outbound mail generation will eventually stop for a few minutes whilst node handover occurs. This process effectively provides zero down time for minor upgrades, other than delaying mail generation and retrieval by a few minutes.
The External Storage feature is last to come online, can take 5m or so after new Nodes have taken over processing, eventually, a page refresh will show things are back and available:
As of 9 FEB, scheduled for fixing in the next build, but also see the Service Desk section at the end for SD specific problems.
(see JSD workarounds at the bottom of the page)
Due to limitations in the platform, JEMHC cannot create comments 'as' other users (AC-1080) and is currently always made as the JEMHCloud Add-on user. In order for any comment visibility levels to be set, the JEMHCloud Add-on user needs to be applicable:
- Where groups are used for comment visibility, the JEMHC Add-on user needs to be a member of a listed group.
- Where visibility levels are used, a simple way to get the right outcome is to add the project Role: *atlassian-addons-project-access* to each visibility level required. JEMHC Add-on user must be in that role for any project wanting JEMHC to do anything useful.
Attachments not being included in outbound notifications
In order to include attachments in outbound notifications the JEMHC Addon user must have permission to get at that issue, this means that the Project Role atlassian-addons-project-access must contain the JEMHC addon user and that role should be listed in any applicable issue security scheme:
Outbound events are listed as IGNORE
When JEMHC > Notifications > Mapping: Only send notifications when a comment is present is set, JEMHC will filter events that do not contain comments, and in the related report will say:
(Email Users): Email hasn't been sent as no useful information was displayed based on the used template.
What is happening is that a user has just edited a field (e.g. quick edit?) or did not make a comment during a issue edit operation. This feature is designed to stop excessive notifications for trivial changes. If you want to start broadcasting individual emails for things like a status change, deselect Only send notifications when a comment is present.
|Notifications||Edit Dialog (field is center screen)|
Inbound mail has just stopped
As a JEMHC customer a Plan comprising of Messages and Data is allocated, based on the number of JIRA users and are refreshed at the start of every month (e.g. 750msg/200MB), if you look at your JEMHC License page you'll be able to see your usage over time. The intent of Plans is to be able to scale the JEMHC resources appropriately that can be consumed on a monthly basis. We have estimated usage for each tier (and will continue to revise, probably upward!), however at this time, its likely you have just exhausted your plan. This is entirely planned and expected behaviour to counter runaway mail generation/consumption/overuse scenarios. The JEMHC Licensing screen will let you know via a visible banner, navigating to the Usage section, you'll be able to see more about current status:
You can track usage history over the last month to see if this is an expected general usage or a peak:
What happens to inbound/outbound messages
When you exceed plan, its designed to not impact users, outbound notifications continue to go out (and count, even beyond your Plan), but inbound mail retrieval stops. As soon as there is credit, everything catches up. We have thought long and hard about doing this, it seems like a good outcome for all, under the circumstances.
Notifications - I never got notified!
Notifications are sent when your instance passed 80% capacity (or what you define, see below) to addresses linked to your JIRA account (the contact users for your system). As you passed through your plan capacity, a further 100% capacity notification would also sent to the same address(es). In both notifications there was a description of what was occurring, what options there were, links to online purchase and documentation. Further addresses to be notified can be set in: JEMHC Licensing > System Notifications
Offering the JEMHC service without limits is not possible, the Plan limits are a best guess on average usage, and of course are subject to change, we have lots of 10 seat JIRACloud users who are working fine within the allocated Plan, if you're expiring half way through the month or sooner, you're at the upper end of the bell-curve for usage and so need to do something about it.
As you are still under evaluation you don't need to spend any $ yet, the point of evaluation is to allow you to see first hand what a typical usage looks like, and to take steps as are appropriate. We hope that you will be able to find a cost effective solution with JEMHC, there are options (see JEMHC licensing
for more details):
are a way to credit your account with more message and data capacity, that is only used when plan is consumed, and lasts for a year, a fair outcome. We do review the DataPack pricing based on feedback, the low end 10$ users are feeling some pressure, unfortunately, most users are 10$ users, those who have higher than expected usage need to support that. DataPacks are not 'storage' level costs they are 'processing' costs, all that data is not just dropped onto cheap S3 storage, its carefully handled through highly available multi-AZ clustered nodes, which are not cheap to run. Costs go up as your usage does, so you need to support that.
provide a more cost effective way for users to bump their plan up to higher tiers but can be purchased only in advance for a 12 month period (we just aren't geared for subscription), they are non-refundable and non-transferrable. This is the recommended route for most lower tier users who just need a bit more capacity, and then, should it be required, peaks can be dealt with via DataPacks.
Can't Set the Reporter / Assignee
At the moment, the permission requirements are hard-coded, in the cases that the JEMHCloud Addon is not the reporter (ie workaround user is set), then:
- User needs "BROWSE" permissions to be REPORTER
- User needs "BROWSE" to be a WATCHER
- User needs "COMMENT_ISSUE" to COMMENT the issue
- User needs "COMMENT_ISSUE" and "ASSIGNABLE_USER" to be the ASSIGNEE
Restating, setting the reporter is possible because it is an attribute of an issue. Comments do not
have this property and cannot
be made by Atlassian Connect addons to be made by
a given user, as Atlassian Connect does not support remote addons impersonating users. Please vote and watch:
If you have created a notification template from scratch its possible that the template doesn't include the following when a comment is rendered on screen.
This is required, and used in JEMHC System Templates to flag that a comment has in fact been rendered, and so a notification should be made, the following is the snippet required. If in doubt, use a System Template first to be localise the source of the problem.
If the template doesn't flag the printer comment, you may see something like this in the event's report
.. Email hasn't been sent as no useful information was displayed based on the used template (firstname.lastname@example.org)
Subject Field Processor not working with Custom Field names with spaces
Where field names contain spaces, replace with underscores (below). Use of customfield_12345 format will work real soon.
#The_Name_Of_Custom_Field_With_Underscores_Instead_Of_Spaces="The value quoted if it has spaces"
XXX Custom Field not found in the selected project
If this advisory is seen, check that the custom fields are on all screens used by the project, which is required to enable JEMHC to use them:
If the cause is not immediately clear, in order for support to help use the Tools > Project Metadata (download option) for the project concerned, and attach on a support issue. After looking up a project, the metadata lookup allows it to be downloaded:
Project key XXXX is invalid
When viewing a Profile, JEMHC shows some Configuration Advisories, used to describe any problems, e.g.:
Where the project key XXXX is completely valid, this problem means that the project does not allow JEMHC access. For example, your project perms should look something like below, specifically JEMHCloud Add-On is in the role atlassian-addons-project-access which is referred in the projects Permission Scheme:
These roles get reflected in the default project security scheme, some of which is shown below:
If the Role atlassian-addons-project-access doesn't have access, JEMHC won't be able to work. If default allocated permissions are changed, be prepared for JEMHC being unable to operate!
Curious Error Messages
Error: Email's Body(any) cannot be loaded. java.io.IOException: Unknown encoding: 7-bit
The Javamail libary used by JEMHC is standards compliant, the correct reference for 7 bit encoded email is 7bit not 7-bit. JEMHC has capabilities to address this (How To Use Pre-Processing Tasks) by enabling Use PreProcessed Message, JEMHC can manipulate illegal content type entries like this, here is what we use:
No Issue Types are available in the setup wizard
Installation wizard does not show issue types if the JEMHCloud Addon user is not (a) listed in the atlassian-addons-project-access role, which should be granted all permissions in the project.
Issue entity properties couldn't be set. Error: You do not have permission to edit issues in this project.
Ignore this, its harmless and will go away soon, Atlassian are working on it:
Errors "Cannot create issue. Error: Field 'reporter' cannot be set. It is not on the appropriate screen, or unknown." and advisories like "Security field does not exist in the selected project."
When creating issues remotely (commenting remotely do not have this problem, though updating the reporter with Directives will likely break also), addons need to provide only fields that are listed in the 'metadata' for creating an issue in a given project, this effectively means what fields are visible on the create issue screen. We found that with v2 Service Desk installed, that our remote addon request was being interfered with, breaking lots.
Seems that the root cause of that is:
However, that’s not all, recently (for us) mails for registered JIRA users were being forwarded (not processed). The cause of this is that the 'reporter' seems to have dropped off the GET /rest/createmeta/ response (example), but only for remote JWT token authenticated addons, and only in ServiceDesk enabled projects. As we were setting the reporter for JIRA related users, it was failing validation, and being rejected:
The v1.0.93 release made on 6 JAN works this problem scenario, checking the create meta for the reporter, and if not there, falls back to treating the external user as an email only user, storing the address in a custom field. This improvement also caters for scenarios where the reporter is genuinely not present.
JEMHC can't connect to your hosted mail server due to Firewall problems
JEMHC using a specific IP address for outbound connectivity (18.104.22.168) this should be allowed in your firewall for whatever service is being accessed.
Why does JEMHC complain about not being able to lookup a user by address?
JEMHC needs a workaround user/password to be defined that has the JIRA Global Permission BROWSE USERS. Why should I have to create a work around user?
Atlassian created a communications framework called Atlassian Connect that is the standard way for remote addons to interact with Atlassian Cloud. This framework is designed bottom up to be secure, and that means white-listing addons to be able to do some tasks. Some operations still do not work as an Atlassian Connect client. For some features to work as we want them we need to fallback to the REST API to go-around Atlassian Connects limitations.
Issue has been created but it cannot be read
The following error message can appear, even though you have already verified that the JEMHCloud user has the correct permissions to Create and Edit the issue. What else can be the cause? If you have issue security set for created issues, make sure that the JEMHCloud user is in the relevant role/group to get this security level.
Error - Issue has been created but it cannot be read. Error: You do not have the permission to see the specified issue.
Account is required
The following error message can occur when there is an active Tempo plugin on the JIRA cloud instance.
Error - Cannot create issue. Error: Account is required.
This is a result of the Tempo plugin creating the custom field Account and setting it to Required in the field configuration.
More information and a resolution can be found here: https://confluence.atlassian.com/jirakb/users-can-t-create-issues-account-account-is-required-717423406.html
Error - You do not have the permission to see the specified issue.
The following error message can appear when trying to comment on an issue that has a security level set.
Error - Issue has been created but it cannot be read. Error: You do not have the permission to see the specified issue.
In order to comment on issues with a security level, the JEMHClound Add-On user must also be able to view the issue (must be included in the issue security level).
Mail Server Problems
Unexplained / High levels of Maintenance notifications
Sometimes you will notice in JEMHC Licensing, the usage charts, these describe the kinds of traffic that are being consumed/generated by JEMHC. All message types count towards your plan, so its in your interest to reduce redundant messages. It is possible that configurations are working as expected, but the following should help you to decide if this is appropriate or not:
Email notifications follow this path to JIRA:
Email -> Mailbox -> JEMHC -> JIRA
The mail in the mailbox has an addressee (to/cc/bcc header) that the JEMHC profile is configured to match through CatchEmailAddresses. The reason there is this match is so that JEMHC can remove the Inbox address from the participant list stored in JIRA (there is no guarantee that the mailbox address is in the to:)
When your system picks up a mail TO: someone else that is not a catchemail address. Default behaviour is to forward that to the 'forward' user listed in the JEMHC Profile. Not doing this would result in a mail block, stopping any further processing.
Now, what can happen is that if someone uses the Mailbox directly, e.g. Gmail, and sends mail, that mail TO: email@example.com
ends up in the SENT box. But, if you are using POP, that mail will be 'found' as new, and tested, of course, firstname.lastname@example.org
is not a Catchemail match, so it will be forwarded. This results in 1 message pull, and 1 message send that is effectively redundant.
You can switch to IMAP, or stop using a Mailbox interactively (if that's the cause).
How to know WHY messages were not processed
When Maintenance messages are sent, they will be sent to the Profile > Forward User Email Address. Obtaining that and reviewing the email that will be 'attached' will help inform why it was forwarded. There can be other 'good' reasons, but comparing 'who' that email is addressed to VS your Profile Catchemail address will inform you as to the cause, and what to do next. If you have that attached email, please mail it to email@example.com with details of your inbound mailbox address, and attached Profile export.
Duplication Outbound notifications
In some situations, having a SMTP time-out too low can result in the client (JEMHC) aborting the delivery of a message, however, the SMTP server may have got 'the data' and is actually able to deliver it without our now terminated connection, then, JEMHC may retry later. If you see multiple notifications of the same message, check your time-outs. Overloaded mail servers may take time to complete handling of deliveries, if in doubt, go up to 60Seconds or higher.
Connection Timeouts (connections flipping offline /online)
This is very common. Some mail servers take much longer to respond than others (due to their loading), when Messages Sources go 'offline' it means that the server did not respond within the expected configured time-out, set in the Message Source. The default value is 30S, this should be adequate for most servers, try increasing the value.
If you have inadvertently introduced a mail loop, your mailserver may block your account from making connections in the short term.
AuthenticationFailedException: 454 4.7.0 Too many login attempts, please try again later
Atlassians Mail Services
The short story: No, don't do that, use a specific external mail host.
The longer story: Lots of users start out trying to use the Atlassian mail servers, JEMHC wasn't specifically designed with this in mind, its primarily designed to connect to an external mail server. The (anecdotal commentary from users) issue with the Atlassian mail servers is that periodically the related servers restart and this resets the related passwords on the server and in the JIRA instance (so no problem for JIRACloud, but kind of a problem for JEMHC).
There is no official Atlassian documentation, this is the response to a clarification request:
An Atlassian instance's mail server is meant to be used only by the instance. Its default use would be as an SMTP mail server and to create emails arrive in the mail box as comment in related issues.
Atlassian don't provide access to the mail account to any other usage - its password is not published anywhere and any changes made to it will be reverted back to default setting automatically.
I'm afraid there's no published article or documentation which can address similar concern as of now.
Cannot send test message to Message Outbound
If you are using a brand new gmail account, after entering the configuration, on first click of Test Configuration button, it will succeed. However, subsequent tests will fail.
This may be because the new gmail account has been suspended. If this is the case, you will have this waiting in the accounts inbox:
Gmail will ask you to verify access by entering a verification code. Do this in order to unblock the account. Note that the JIRA outbound message test will still fail at this point. While logged into the Gmail account, compose and send an email to itself! Outbound message tests will now work.
Message Outbound is failing and no error is given by JEMHC
From the Edit Message Outbound screen, when clicking Test Configuration you may get a failed test along with the following message:
This scenario can occur when the Gmail account being used is not set to "allow less secure apps". A tell-tale sign that this is the case is that the gmail account has been sent an email like this from Google:
By either clicking the "allow access" link in the email, or by turning this setting ON in the Google accounts security settings, JEMHC can start using the account for outbound messages. Note that it could take several minutes for the change to take effect.
SVG Icons not rendering
Gmail uses a proxy/cache for image retrieval, this works well for png and jpg types that are publicly available via a CDN. It doesn't appear that this cache works with SVG content, so Gmail will just render a broken icon. Its not a JIRA/JEMH bug, its Gmail. No workaround is possible for those cases.
Gmail and mail loops
Should you get lots of mail loop notifications with a gmail account, check that your sender is not in the gmail "Send Mail as:" list, which, if present, will cause all sent mail to be delivered to the inbox of the Outbound Mailserver, which is confusing!
Gmail and POP (causing high levels of plan message/data consumption)
Gmail and POP will work just fine if you do not use the Gmail UI to send mail. Currently, if you do this, that mail (the one you just sent) will be retrieved by JEMHC through POP (no, this isnt a bug, its how gmail seems to work with UI sent messages). This message will then be rejected etc. Overall, this will result in double hit on your plan, as the message has to be read, then rejected and forwarded to your JEMHC profile user. We have tested IMAP, it will work much better in this situation. BUT before just turning on IMAP verify that you have set the 'point' at which mail will be read to be 'now', otherwise JEMHC will retrieve ALL your mail ever, and exceed your plan in doing so. Current JEMHC will not allow you to create a mail connection if the messages present would consume your plan, to help try and avoid this kind of thing.
If you want to Use Gmail POP with JEMHC, you must not send mail from the UI, we believe that a client sending mail will not cause problems.
IMAP has been validated as not having these problems with GMail.
Gmail SMTP connections permanently offline
Gmail is quite clever, it knows what geographical area you tend to access a given mailbox from. If someone from a different area attempts to use your acct, bells go off and access is denied, perhaps when Validating Mail Connections with Telnet you noticed a gmail error:
530-5.5.1 Authentication Required. Learn more at
530 5.5.1 http://support.google.com/mail/bin/answer.py?answer=14257 ej10sm48089217wib.1 - gsmtp
This is usually accompanied by a related "Message outbound 'xxxxx is disabled", in this case, logged in as that mailbox user follow the link and click "Allow less secure apps to access your account", then access:
It prompts to enable or disable access for less secure apps, ensure Enable is listed.
Gmail connections are offline/blocked:
Gmail as a service provider wants to limit the polling churn, it does this by requiring apps (like JEMHC) do not poll more frequently than 10 minutes, or the related accounts could be blocked), see bullet 4 in page linked below:
Gmail says "likely unsolicited mail"
Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked. Please visit 550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131
Gmail Bulk Sender Guidelines
For more details about Gmail as a bulk sender, see https://support.google.com/mail/answer/81126?hl=en
Sending Mail from: a different account that the outbound mailbox
Microsoft Office365 / Outlook.com
Using Exchange Web Services (EWS) Protocol, mail get blocked by Microsoft on the way out
Delivery has failed to these recipients or groups:
Diagnostic information for administrators:
Generating server: MM1P123MB0843.GBRP123.PROD.OUTLOOK.COM
Original message headers:
We found in development that after configuring an EWS Office365 outbound transport, that sending a test message 'completed' from the viewpoint of JEMHC, that the Office365 environment blocked the message and returned it as non deliverable. If this affects you, you will need to log a support case with Microsoft and refer our case (red, below), there is no specific KB article to follow.
- Office 365 Ticket #30126-5190003
Shared Mailboxes (outbound SMTP)
These are not supported by an Java client. See toward the end.
• All the mailboxes must be license enabled Exchange Online mailbox, and cannot be shared mailboxes.
• The SMTP set to port 587
• Transport Layer Security (TLS) encryption enabled in the relay software
• The mailbox server name must be correct.
There is an online tool Microsoft hosts for diagnosing their products:
If you are unable to connect with that, its unlikely JEMHC will be able to connect either. JEMHC support can't diagnose you mailserver, you will need to contact the mail service provider.
Microsoft Office365 / Live.com auth problems
Like Gmail, Microsoft has anti-hack measures in place, meaning that when JEMHC tries to connect it will usually be flagged /blocked as an unexpected access coming from the USA (where JEMHC is hosted on AWS). Likely you'll see various error messages when trying to configure JEMHC using (for example) smtp-mail.outlook.com. When this happens, you'll need to login to your mail account interactively (e.g. mail.live.com ), in your mailbox may will be a messsage Microsoft account unusual sign-in activity with a link to settings, requiring a second-factor authentication (code), then, you will be able to review recent usage, do that, locate the login attempt from USA for the time JEMHC was configured, and say 'that was me'.
22.214.171.124 is the Public IP for outbound communication from JEMHC
Once you do that, there will be a delay while the settings apply, in which you get:
Cannot send test message to message outbound. Check credentials carefully! Check your mail server's Firewall. Error from server: Failed to close server connection after message failures; nested exception is javax.mail.MessagingException: Can't send command to SMTP host; nested exception is: java.net.SocketException: Connection closed by remote host. Failed messages: com.sun.mail.smtp.SMTPSendFailedException: 451 5.3.4 Requested action aborted; Local processing error.
After a while, things settle down and your mail should be delivered.
o365 Authorization failing for retrieval using POP/IMAP
When using POP and IMAP, per user configuration is needed:
Client does not have permissions to send as this sender
This is currently a common problem with business office365 users (if you're using the smaller scale/personal office365 plans/configuration, it just works). The page commonly referred for configuration is:
See How to Allow a Multi-function Device or Application to Send E-mail through Office 365 Using SMTP.
Errors: 550 5.7.501 Access denied, spam abuse detected
If the emails JEMHC sends via SMTP or Office 365 EWS bounce back to the inbox with the following messages
Step 1: Register JEMHC by IP on the Microsoft Delist Portal
Use the DELIST PORTAL @ https://sender.office.com/ to delist JEMHC (Public IP is 126.96.36.199) to be able to send through your Office365 system:
Step 2: Acknowledge email sent to your office365 domain mailbox
Step 3: Complete the action
Step 4: Review completion screen
Step 5: Wait
The application of this change isn't even remotely real-time. Allow up to 24hrs before contacting Microsoft Support for further advice - we will not be able to assist.
Too many recipients
We're tracking this at
TenantAttribution; Relay Access Denied
The following error will be found in JEMHC logs for affected hosts. I've logged this so customers can find it.
Error: MailSendException: Failed messages: javax.mail.SendFailedException: Invalid Addresses;
nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 550 5.7.64 TenantAttribution; Relay Access Denied
Maybe the follow help:
Verify your addresses
To rule out JEMHC and any connectivity issues you can test delivery (apparently!) with:
A related community article:
Allow me to share the solution you've found out here for others:
"1. The scanner email address is hidden from the address list so I unhide it
2. Reverse the permission, the scanner account should have the "SEND AS" permission to the user mailbox and not the other way around."
If you encounter any issue when using Office 365, please post in our forum. We're glad to offer help.
Have a great day!
Setting issue request type via custom field defaults
Instances with ServiceDesk installed where the user is not a JSD Agent (JSD application access) prevent commenting on Software/Core projects:
Workaround at this time is disable the ActAsUser function, see Profile > Act As User (which is on by default).
Fresh-Install configuration checklist
When integrating JEMHC with a JSD Project, the following steps will be needed to avoid errors like "The previously selected project key is not valid anymore. Issues cannot be created":
- The JEMHCloud Addon must be an JSD Agent in order to operate on the issues, this is over and above Project Permissions, as JSD vetoes some of them. You can do this by
- Going to Service Desk > Manage Agents, and adding JEMHCloud Addon as an agent. Currently, each project that an agent is expected to work on must be explicitly selected.
- Add the JEMHCloud addon user to the Service Desk Team role in the project:
- Email user custom fields will need to be added to the Create Issue Screen and View/Edit Issue Screens.
- Go to Issues > Screens > JIRA Service Desk Screen for Project xxx and click the Configure action, enable the Email user custom fields:
- Email Sender Name
- Email Sender Address
- Email Participants
- Fix issue type and sub-types
- Set the Issue Type (example) to be IT Help.
- Set the Sub-Task Issue Type to be None (this prevents use of an inherited sub-task issue type from the Default Project Mapping)
- In order to lookup a registered JIRA users via email address, so as to set the Reporter, check that the JEMHC > Workarounds >Workaround user has been defined, and that it can lookup a user.
Permission Scheme problems / JEMH does not have permission
When JSD is enabled, it replaces some specific and individual permission checks with the result that the Permissions you think have been allocated are not (https://jira.atlassian.com/browse/JSD-1739)
This is a complex area to get right, its definitely still a work in progress:
- What makes JSD Comments Public or Private
In Jira Service Desk, if you use a path value as follows it may not be shown in JSD comments as expected:
This is a bug within JSD:
Ability of a JIRA account holder (even JSD) to bring in other users to the issue on CC (participants)
You may see the following, where a custom-field (which you will have setup as the Email Participants in your Profile) seems to not be set. This isnt the case, where JSD is involved, its vetoing the 'user' who sent the mail from editing the issue because they are not a JSD Agent. Clearly this is never going to be the case for a standard JIRA Account holder (even a JSD user has an 'account') user.
There has been a ERROR processing a message.
* Error - Cannot comment on issue. Issue couldn't be updated. Error: Field 'customfield_10612' cannot be set. It is not on the appropriate screen, or unknown.
* Info - Profile: id=1, Name=PPL Support, Mapping=Default
* Info - There has been an error processing a message.
* See file 'original-email.txt' attached.
What needs to happen, specifically for this case, is that JEMH needs to detect JSD is setup on a given project, to make comments etc as appropriate, but then, to switch into the 'default user' persona in order to update fields.
Ability of a Non-JIRA account holder (email only user) to bring in other users to the issue on CC (participants)
JSD requires that users are Agents in order to edit issues, that means, when supporting email only users the JEMHCloud addon user must be made a JSD agent, in order for it to be able to set the custom fields with values (additional email participants).
Atlassian has indicated that Addon users "don't count" as Agents in Cloud instances, so should not affect customers with lower numbers of agents.
How to set the Reporter on issue creation, based on the sender of the email
JEMHC is a remote addon, and as such, cannot 'impersonate' users (https://ecosystem.atlassian.net/browse/AC-1080) and as a result, all interactions with JIRA through Atlassian Connect are currently done as the JEMHC Add-on user. When creating issues, it is possible to set the reporter attribute of issues, but in order to do so, JEMHC needs to lookup a user by email address, which remote addon's still cannot do (https://ecosystem.atlassian.net/browse/AC-1014). To provide this necessary feature, JEMHC has a Workarounds section, in it, you can provide a username and a password for a user in your JIRA that has the BROWSE_USERS global permission (its not possible to add groups or permissions to Add-on users). The workaround user can be validated, lookup an example email address to confirm.
Now, with the workaround user in place, JEMHC can find the reporter to set. Next up is manipulating project permissions to allow this to work:
- In JIRA, create a group, e.g. service-desk-customers
- In your JEMHC profile, enable User auto-creation, and set the auto-join group to service-desk-customers
- In your Project Permission Scheme, give the service-desk-customers group the Browse Project permission - Further permissions may be required, wherever the pseudo Role "Service Desk Customer - Portal Access" is mentioned, potentially a JEMHC remote user may need that permission!
Ability to set Security Level
- ACJIRA-287 - Security: section is not presented in createmeta to JWT authorized user (required to set the Security Level)
You are right, add-on user is system account, and it should not consume any license from customer point of view. Fortunately, at present, SD veto logic has ignore counting license for those users belongs to atlassian-addons group. The only thing we need is to add atlassian-addons group to JIRA Service Desk agent access global permission and make sure this group is assigned to Service Desk Team role as well.
JEMHC is not able to create issues for JSD v2 signup users without mass allocation of a group that has CREATE_ISSUE, which results in further problems
The workaround for this is to turn off the Service Desk Comment module, enabling standard JIRA comment visibility features to be present. Of course, this means agents need to remember that old trick of setting their comments private etc. Access ServiceDesk from Manage Addons, and expand on 'modules enabled', to see service-desk-comment-field
As it looks only possible to 'flag' comments for JSD purposes as Internal after creation, meaning, the Event has already fired, and the notification is potentially underway.
Attachments are getting duplicated
JEMHC has a mechanism for detecting by hash whether an existing attachment (e.g. image) already exists, typically, this would be when signature images get through. Check your profile's Attachment Duplication Strategy:
- Profile > Project Mapping > Issue > Attachment : Retrieve issue attachments and hash
Current AC issues:
|User email visibility||Masked (i.e. user at example dot com)|