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

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 ( JEMHC-1224 - Getting issue details... STATUS ) 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 support@thepluginpeople.com for a confirm.

The add-on host returned HTTP response code 401 when we tried to contact it during installation.

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

Repeat Evaluations

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.

• See App licensing#EvaluationPeriod

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.

JEMHC has a public IP addresses for service interactions that are specific to a deployment region (See below), they should be allowed to connect to your network on the ports that you have configured:

 From 1 FEB 2024, JEMHC will have TWO IP addresses (for higher availability) in the US region, see https://thepluginpeople.atlassian.net/l/cp/dPNnjHVX for more.

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:

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.

• https://confluence.atlassian.com/adminjiraserver071/configuring-jira-application-options-802593101.html

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

• In order to pro-actively check hosts, we need a new API method, see: https://ecosystem.atlassian.net/browse/ACJIRA-411

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:

Comments with visibility settings are leaking to email only users

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.

• JEMHC-314 - Getting issue details... STATUS  (see JSM workarounds at the bottom of the page)

Comment visibility can't be set

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

Only send notifications when a comment is present is set

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)

Show fields contain unrecognized field identifiers

This is related to JEMHC-3119 - Getting issue details... STATUS and related to if the users has configured additional fields to show as per documentation :

• Issue Update events: Select fields to be shown in a Jira/Service Management/Transport issue update notification
• Issue Create events: Add/Remove (Custom) field to Jira/Service Management/Transport Desk Create Notifications

If you have configured JEMH Notifications to render non-default rendered fields via Show fields arrays then if there is a Custom Field set as an element using it's custom field name and not the customfield_id pattern i.e. customfield_1000 then JEMH cannot retrieve the correct values from the Jira defined webhook context specifically from context.issue.fields. This also affects certain system fields i.e. Request Participants. Please ensure that the field identifier values set in the related transport show fields array are as expected in your Jira Webhook. If you need to view an example Jira webhook related to an issue please see: Preview Context; once you have a preview context navigate to the context.issue.fields JSON node and look up the desired custom field identifier.

Inbound mail has just stopped

What happens to inbound/outbound messages

Notifications - I never got notified!

Evaluation Users

Can't Set the Reporter / 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:

$jemhUtils.setCommentRendered() 

.. Email hasn't been sent as no useful information was displayed based on the used template (user@company.com)

#The_Name_Of_Custom_Field_With_Underscores_Instead_Of_Spaces="The value quoted if it has spaces"

Configuration Advisories

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:

• https://ecosystem.atlassian.net/browse/ACJIRA-306

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.

• https://ecosystem.atlassian.net/browse/AC-1417

Seems that the root cause of that is:

• https://jira.atlassian.com/browse/JSD-970

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:

• https://ecosystem.atlassian.net/browse/ACJIRA-286
• https://ecosystem.atlassian.net/browse/ACJIRA-287

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 (54.210.55.45) 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:

How to know WHY messages were not processed

Duplication Outbound notifications

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.

Gmail

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.

• http://stackoverflow.com/questions/20815613/svg-images-blocked-by-gmail-proxy
  
  

  I've heard back from Google support, and they've confirmed there are currently no plans to support SVG images in the proxy. They said they account for only 1 in 100,000 email images.

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.

• See the Google forum post on this: https://productforums.google.com/d/msg/gmail/EGg1RyFCpGk/hMdpZxqwcSsJ

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:

• https://www.google.com/settings/security/lesssecureapps

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:

• https://support.google.com/mail/answer/14257

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

• Adding SPF records : https://support.google.com/a/answer/33786

Sending Mail from: a different account that the outbound mailbox

• https://support.google.com/mail/answer/22370?hl=en

Microsoft Office365 / Outlook.com

• Non Delivery Report error code lookup

Using Exchange Web Services (EWS) Protocol, mail get blocked by Microsoft on the way out

Delivery has failed to these recipients or groups:

aaaa@gmail.com (aaaa@gmail.com)
Your message wasn't delivered because the recipient's email provider rejected it.

Diagnostic information for administrators:

Generating server: MM1P123MB0843.GBRP123.PROD.OUTLOOK.COM

aaaa@gmail.com
Remote Server returned '550 5.7.501 Access denied, spam abuse detected. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653'

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. 

Connectivity Checking

There is an online tool Microsoft hosts for diagnosing their products:

• https://testconnectivity.microsoft.com
  

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'.  

 54.210.55.45 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:

• https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/pop3-and-imap4/enable-or-disable-pop3-or-imap4-access

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 54.210.55.45) 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  JEMHC-1204 - Getting issue details... STATUS

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.

{quote}
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
{quote}

Maybe the follow help:

• https://bobcares.com/blog/office-365-relay-access-denied-error/
• https://justaucguy.wordpress.com/2015/05/14/office-365-550-5-7-64-tenantattribution-relay-access-denied/
• http://answers.microsoft.com/en-us/msoffice/forum/msoffice_outlook/550-5764-tenantattribution-relay-access-denied/60670402-f879-4f2e-b358-b6ac1b921840
• https://support.office.com/en-us/article/How-to-set-up-a-multifunction-device-or-application-to-send-email-using-Office-365-69f58e99-c550-4274-ad18-c805d654b4c4?ui=en-US&rs=en-US&ad=US

Verify your addresses

To rule out JEMHC and any connectivity issues you can test delivery (apparently!) with:

• https://technet.microsoft.com/en-us/library/dn592151(v=exchg.150).aspx (see How do you know this worked section)

A related community article:

• http://community.office365.com/en-us/f/158/t/227898.aspx
• http://stackoverflow.com/questions/25357440/550-5-7-1-client-does-not-have-permissions-to-send-as-this-sender-office365
• http://community.spiceworks.com/topic/363988-office-365-and-smtp-realy
• http://community.office365.com/en-us/f/156/t/251434.aspx
  

Suggested Answer

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!

Thanks,
Colin

Service Desk related issues

Setting issue request type via custom field defaults

User with no group has BROWSE and COMMENT_ISSUE permissions but cannot comment on a Software/Core project

 Instances with ServiceManagement installed where the user is not a JSM Agent (JSD application access) prevent commenting on Software/Core projects:

• https://ecosystem.atlassian.net/browse/AC-2212

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":

1. 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
   1. 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.
   2. Add the JEMHCloud addon user to the Service Desk Team role in the project:
      
2. Email user custom fields will need to be added to the Create Issue Screen and View/Edit Issue Screens.
   1. Go to Issues > Screens > JIRA Service Desk Screen for Project xxx and click the Configure action, enable the Email user custom fields:
      1. Email Sender Name
      2. Email Sender Address
      3. Email Participants
3. Fix issue type and sub-types
   1. Set the Issue Type (example) to be IT Help.
   2. Set the Sub-Task Issue Type to be None (this prevents use of an inherited sub-task issue type from the Default Project Mapping)
4. 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)

• Apparently JEMH (default user, and any participants) needs to be specifically listed as a collaborator in current JSD releases https://jira.atlassian.com/browse/JSD-931

• Some help in resolving errors in JSD enabled projects: https://confluence.atlassian.com/display/SERVICEDESK/Resolving+permission+scheme+errors

JSD Comments - Public or Private

This is a complex area to get right, its definitely still a work in progress:

• What makes JSD Comments Public or Private

Service Desk comments not rendering Backslash (eg paths)

In Jira Service Desk, if you use a path value as follows it may not be shown in JSD comments as expected:

C:\Program Files\Company\Software

This is a bug within JSD:

• https://jira.atlassian.com/browse/JSDCLOUD-9159

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.

Messages:
    * 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.

Current workaround:

• Upload the attached mail and/or convert a message from Auditing to a Test Case
• Remove additional recipients

• Run the mail against the related JEMHC Profile 

• Manually update the custom field with the participants required
  

 See  JEMHC-497 - Getting issue details... STATUS  for more.

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.

Service Desk 'Internal' comments get broadcast to email only users regardless

• https://jira.atlassian.com/browse/JSD-1484

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

• https://jira.atlassian.com/browse/JSD-1473

Service Desk comments created by JEMHC are getting created as "Internal" comments

• https://jira.atlassian.com/browse/JSD-1505
  

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

And when Comments are not made internal by default, ironically, JEMHC won't then be able to make any comments internal

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.

• https://ecosystem.atlassian.net/browse/ACJIRA-320

Attachments

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

Post-functions

Current AC issues:

• https://ecosystem.atlassian.net/browse/ACJIRA-455
• https://ecosystem.atlassian.net/browse/ACJIRA-326
• https://ecosystem.atlassian.net/browse/ACJIRA-443
• https://ecosystem.atlassian.net/browse/ACJIRA-442
• https://jira.atlassian.com/browse/JRA-43448

Related Articles

• Page:
  How JEMHC Calculates Data Usage
• Page:
  How to export your profile
• Questions:
  Cannot read messages from message source. SocketConnectionException: SocketTimeoutException: connect timed out
• Page:
  Setting a custom field value
• Questions:
  How can I extract the original sender & recipients from a message forwarded to support by an agent?