/
Common Problems

Common Problems

Owned by Andy Brook [Plugin People] (Unlicensed)
Last updated: Jan 06, 2025 by Andy Brook [Plugin People]

This page summarises common problems that can affect JEMH for JIRA Server and provides solutions for them.

If you are looking for common problems experienced using JEMHCloud for JIRA Cloud, please see JEMHCloud Common Problems.

It may also be worth checking Atlassian's JIRA Knowledge Base and one of its pages Mail and Mail Handlers Troubleshooting.

JIRA Environment Parameters (eg to disable mail) are documented here.

Atlassian's Support End of Life Information

A reminder that Atlassian support for Jira Core/Software 7.2 and ServiceDesk 3.2 ends on 23 AUG 2018 - https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html.  As long as your JEMH license is current, you can still get our support on these JIRA versions but we won't be actively porting fixes to EOL compatible versions of JEMH.


JEMH (for Server only) Is not licensed through Atlassian Marketplace

Its historic, and with JSD Agent tiers, now a bit more complex.  Its on the list but is not on the short term roadmp.  JEMH remains a vendor licensed addon at this time, all renewals /quotes/ invoices to go through sales@thepluginpeople.com

JEMH-5982 - Getting issue details... STATUS

Jira Server technical upgrade notes (7.13.x - 8.13.x)

The follow covers key features Atlassian included in these releases:

JavaMail FAQ

JIRA uses the JavaMail library to process all mail, therefore so does JEMH.  There is a JavaMail FAQ that also contains combined experience of JavaMail users working with disparate mail servers, and the various integration problems these throw up - as well as hopefully solutions, its always worth a look:

JEMH Server Specific

Couldn't flush user prefs: java.util.prefs.BackingStoreException: java.lang.NullPointerException

This is caused by using JDK 8 and JEMH licensing, and is harmless. Workaround steps are listed below:

Log Volume reduction workaround

JEMH doesn't use UserPreferences, its not specifically common to Atlassian apps, but I couldn't judge or assert that they aren't used by any application or add-on, even if there were other users, this problem would likely affect them also. Extending the retry (as per site above) is one way, setting an environment option to 30 min

Extend the retry, to reduce the frequency of the misleading error message, add the following startup variable:

JAVA_OPTS="$JAVA_OPTS -Djava.util.prefs.syncInterval=900 "


(see Atlassian docs for background), eg for linux installs (30 is the default (seconds), 900=15 minutes, 3600 is hourly, 86400 is daily)

Dark Feature incompatibilities ( JEMH < 4.2.18 )

S3 Attachment storage breaks JEMH

(warning) "This feature is currently available behind the feature flag: com.atlassian.jira.attachments.storage.configurable. When enabled, it introduces breaking changes to the API and might also break some Jira apps."

To get this to work you need to be on JIra 9.13+, JEMH 4.2.18 has the fix for Jira 9.13+, JEMH 5.0 supports this already for Jira 10+


Jira 10 Upgrade problems

Custom Velocity Templates not rendering or custom content calls (to Atlassian components) not working.

As referred in https://confluence.atlassian.com/jirasoftware/jira-software-10-0-x-release-notes-1416825224.html#JiraSoftware10.0.xreleasenotes-velocity , apps now have to declaratively list app classes and methods, this doesnt include Atalssian components, that it may not have allowed.  Referring to such classes can cause templates to break/fail to render.

Next steps

Disabling the new security features is a short term solution.  In order to gain component level allowlisting, you'll need to engage Atlassian via support.atlassian.com 

Velocity template file allowlist
To disable the "File Allowlist" feature in Jira, follow these steps:

  1. Locate the 'velocity.properties' file.

  2. Find the following key in the file: 'resource.loader.file.allowlist.enabled'.

  3. Change its value to 'false'.

  4. Save and close the configuration file.

Alternatively, you can also remove the entire line containing 'resource.loader.file.allowlist.enabled' from the configuration file.

Make sure to make the change on each Jira node and then restart it to apply the new configuration to the node.


Velocity template file type allowlist
To disable the "File Type Allowlist" feature in Jira, follow these steps:

  1. Locate the 'velocity.properties' file.

  2. Find the following key in the file: 'resource.loader.filetype.allowlist.enabled'.

  3. Change its value to 'false'.

  4. Save and close the configuration file.

Alternatively, you can also remove the entire line containing 'resource.loader.filetype.allowlist.enabled' from the configuration file.

Make sure to make the change on each Jira node and then restart it to apply the new configuration to the node.


Velocity method allowlist
To disable the "Method Allowlist" feature in Jira, follow these steps:

  1. Locate the 'velocity.properties' file.

  2. Find the following key in the file: 'introspector.proper.allowlist.enable'.

  3. Change its value to 'false'.

  4. Save and close the configuration file.

Make sure to make the change on each Jira node and then restart it to apply the new configuration to the node.



JEMH DataCenter edition licensing problems

See Licensing for current information on Atlassian problems that affect JEMH.

I upgraded JEMH and it now complains about an Server / DataCenter edition mismatch

A bug in the UPM (AMKTHELP-12797) incorrectly downloads the Server edition of JEMH which is not compatible in DataCenter environments (as of 1 SEP 2018 JEMH is available in two editions, Server and DC, its required that the correct edition is used in the related environment).  The solution is to manually download the DataCenter edition JAR from Marketplace - (warning) Be careful, check version compatibility!

I can't upgrade to JEMH DataCenter edition

The process to install JEMH DataCenter is to uninstall the Server version and use Find Apps to search for JEMH again, when executed from a DataCenter licensed instance, you will get the DataCenter edition of JEMH.

I can't generate an eval for JEMH DataCenter edition from Manage Addons

Evals are available from:

Quoting for JEMH DataCenter

JEMH DataCenter edition problems

Concurrent mail retrieval resulting in duplicate issue creation

If you have massive email volume (mailbox perpetually contains > 00's of emails, and/or they are large (ie take time to download) then the following could affect you:

Data Center (7.2.9 / 7.3.6 tested, probably earlier releases too) can cause concurrent retrieval and processing of emails from a common mailbox.  Private support reference PS-14639, public issue tracker (not currently public).

Common JEMH Problems

Emails without a body are not processed

JEMH will usually forward these mails, if you do want to support them, you can define a default 'Comment' payload used as issue description during create:

  • Profile > Issue > Comment

Repeating log errors

The following is a harmless side effect of a library within JEMH Server, tracked internally  JEMH-3889 - Getting issue details... STATUS , 

ERROR: Bundle com.javahollic.jira.jemh-ui [196] Unable to get module class path. (java.lang.NullPointerException)
java.lang.NullPointerException
at org.apache.felix.framework.BundleRevisionImpl.calculateContentPath(BundleRevisionImpl.java:432)
at org.apache.felix.framework.BundleRevisionImpl.initializeContentPath(BundleRevisionImpl.java:365)
at org.apache.felix.framework.BundleRevisionImpl.getContentPath(BundleRevisionImpl.java:351)
at org.apache.felix.framework.BundleRevisionImpl.getResourcesLocal(BundleRevisionImpl.java:515)
at org.apache.felix.framework.BundleWiringImpl.findResourcesByDelegation(BundleWiringImpl.java:1213)
at org.apache.felix.framework.BundleWiringImpl.getResourcesByDelegation(BundleWiringImpl.java:1123)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.getResources(BundleWiringImpl.java:2676)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(Unknown Source)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(Unknown Source)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(Unknown Source)
at java.base/java.util.ServiceLoader$2.hasNext(Unknown Source)
at java.base/java.util.ServiceLoader$3.hasNext(Unknown Source)
at java.xml/javax.xml.parsers.FactoryFinder$1.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.xml/javax.xml.parsers.FactoryFinder.findServiceProvider(Unknown Source)
at java.xml/javax.xml.parsers.FactoryFinder.find(Unknown Source)
at java.xml/javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)
at java.prefs/java.util.prefs.XmlSupport.createPrefsDoc(Unknown Source)
at java.prefs/java.util.prefs.XmlSupport.exportMap(Unknown Source)
at java.prefs/java.util.prefs.FileSystemPreferences$7.run(Unknown Source)
at java.prefs/java.util.prefs.FileSystemPreferences$7.run(Unknown Source)

Workaround:

Log Volume reduction workaround

JEMH doesn't use UserPreferences, its not specifically common to Atlassian apps, but I couldn't judge or assert that they aren't used by any application or add-on, even if there were other users, this problem would likely affect them also. Extending the retry (as per site above) is one way, setting an environment option to 30 min

Extend the retry, to reduce the frequency of the misleading error message, add the following startup variable (see Atlassian docs for background), e.g. for linux installs (30 is the default (seconds), 900=15 minutes, 3600 is hourly, 86400 is daily)

JAVA_OPTS="$JAVA_OPTS -Djava.util.prefs.syncInterval=900 "

One off errors in the log

From time to time you may see the following, caused by periodic housecleaning of the audit history retained data.  It is caused by the slight difference in timestamp between an audit record, and a hint record, where the purge point happens after the audit record but before the hints, so the hints are not purged (happens first) and so when audit records are purged, the last one cannot be removed because that record has child entities with a foreign key reference.  It is not a long term issue, and most likely, will be resolved in subsequent purge operations,  JEMH-6583 - Getting issue details... STATUS  has been logged to address this.

java.sql.SQLIntegrityConstraintViolationException: ORA-02292: integrity constraint (JIRA743USER.fk_ao_78c957_audith1314010416) violated - child record found
at com.atlassian.activeobjects.internal.EntityManagedActiveObjects.deleteWithSQL(EntityManagedActiveObjects.java:118)
at com.atlassian.activeobjects.osgi.TenantAwareActiveObjects.deleteWithSQL(TenantAwareActiveObjects.java:281)
... 2 filtered
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.doInvoke(ServiceInvoker.java:56)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:60)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:70)
at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:53)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.eclipse.gemini.blueprint.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:57)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
at com.sun.proxy.$Proxy2240.deleteWithSQL(Unknown Source)
c


Issue fails to create with indexing errors

Issue creation fails for no obvious reason and JEMH processing details do not suggest why. In JEMH logs you see something similar to this:

2016-09-16 13:20:15,599 atlassian-scheduler-quartz1.clustered_Worker-2 DEBUG [jira.emh.engine.IssueCreationHelper] Create resulted in 0 errors 
2016-09-16 13:20:15,687 atlassian-scheduler-quartz1.clustered_Worker-2 INFO [jira.emh.engine.IssueCreationHelper] issue not created!!!
2016-09-16 13:20:15,687 atlassian-scheduler-quartz1.clustered_Worker-2 INFO [jira.emh.engine.IssueCreationHelper] Error creating issue: Indexing completed with 4 errors

A possible cause of this is that the UNIX open file limit has been reached by the JIRA application.  See here for more information on this, including workarounds: https://confluence.atlassian.com/jirakb/loss-of-functionality-due-to-too-many-open-files-errors-156862102.html

Auditing History purge does not work with "Retain Failures" enabled (JIRA 7.x)

The audit history purge operation fails when the "retain failures" setting is enabled.  The AO streaming API that is provided by Atlassian is "buggy", and means that our once-efficient data reading is not possible (https://ecosystem.atlassian.net/browse/AO-694).  As a result, we have made the decision to remove this purge setting in newer versions of JEMH JEMH-4962 - Getting issue details... STATUS  (resolved in 1.9.41, 1.8.50, 2.0.5).




Custom Field values are cached causing recipients to not receive notifications (JIRA 7.3.0 - 7.3.4 , JEMH 2.1.0 - 2.1.11)

When a custom field on an issue is modified post issue creation the previous values for the custom field are cached incorrectly. The new custom field values will appear to be correct on the issue screen but this change will not be reflected when JEMH sends notifications.

Example:

  • Issue has custom field for CC users
  • Issue is created with CC user aaa@test.com
  • Custom Field for CC users is populated with aaa@test.com, aaa@test.com is notified of issue creation, and any comments on the issue
  • Additional CC user is added to the custom field after issue creation (aab@test.com)
  • aab@test.com will not be notified of issue updates

This issue was resolved in JEMH 2.1.12  JEMH-5599 - Getting issue details... STATUS


Mail fails to be retrieved from mail server

When a network problem prevents JIRA from communicating to its database, scheduled jobs can be halted indefinitely.  If this occurs to the job in charge of pulling mail, no mail will be retrieved.  We believe this affects JIRA 7.0.x and 7.1.x, it is reportedly fixed in JIRA  7.2.0, see https://jira.atlassian.com/browse/JRA-62072 (fixed in 7.2.0+).  Fixing this is therefore not possible in JEMH v1.8.x (JIRA 7.0.x) and JEMH v1.9.x (JIRA 7.1.x)

Oauth / Gmail / Switch to apps that use secure OAuth access

If you use gmail with simple user/pass you may receive email warning of upcoming plans to remove such access:

  1. June 15, 2020 - Users who try to connect to an LSA for the first time will no longer be able to do so. This includes third-party apps that allow password-only access to Google calendars, contacts, and email via protocols such as CalDAV, CardDAV and IMAP. Users who have connected to LSAs prior to this date will be able to continue using them until usage of all LSAs is turned off.
  2. February 15, 2021 - Access to LSAs will be turned off for all G Suite accounts.

Atlassian/Jira is responsible for retrieving mail that feeds JEMH, we cannot support you with related problems, please contact Atlassian support.

OAuth 2.0 was added to Jira 8.10:

Related Jira documentation:

Problems with IMAP

Folder Closed / Repeat Processing

FolderClosedExceptions are always related to your mailboxserver.

IMAP is touted as a more advanced protocol than POP, which is true in some regards, but in some scenarios it can be problematic (see link below).  If you experience FolderClosedExceptions,

Unlike POP which has exactly 1 client per mailbox, imap can discriminate mailbox content through folders, allowing mulitple 'clients' to connect to a common mailbox.  If 'many' connections/folders are used from a common mailbox, it is possible your mailbox will start randomly closing 'long(er) running'  connections in order to satisfy a new one.  For example:

MessageRemoved

If you have concurrent access to a common mailbox its possible that a message may be 'removed' by another handler process, the error is likely to be harmless, unless the configuration caused the message to be dropped.

Performance Issues

In tests we found huge performance issues processing large messages.   If you are have occasional messages that won't process with IMAP, check your mailbox for large messages, its possible they are not able to be downloaded in time, in order to meet mailserver timeouts, or JIRA timeouts.  POP is a much better performing protocol for JIRA usage, as mail handlers require ALL the mail ALL the time, the IMAP 'features' for extracting bits of the message separately are clever but not required here.

Problems with POP

High 'forward' traffic is the result of using POP for mail retrieval on a mailbox that is also used interactively by a person.  What happens is that for interactive mail (experienced in Gmail) that mail sent TO a customer FROM the mailbox, and added to the Sent folder, also gets retrieved by POP, and is then rejected and forwarded.  Reviewing the addresses will show a catchemail Filter match failure, the TO: address not being valid (the customer address).  The only solution here is to stop using the mailbox interactively, or use IMAP (see above).

Notification History tab does not show on issues

Problem: You have event listener enabled and "store notification history" enabled in event listener project mapping.  However, the notification history tab is not showing on issues.

Explanation: There is currently a known bug where if you have a single project mapping with multiple project keys listed in CSV (e.g. "AA, AB, AC"), the notification tab will not be set to appear.  The bug is logged here: JEMH-3999.

Workaround until bug fixed: Separate the projects into multiple event listener project mappings.

Creating duplicate issues to multiple projects fails

In the scenario where you are sending one email to multiple addresses in order to create issues in multiple projects, JIRA fails to create all of the issues.  If Inbound Mail Logging is enabled, the following message will appear:

2015-11-04 14:27:33,512 WARN [PPL2Mailbox2] atlassian-scheduler-quartz1.clustered_Worker-1 ServiceRunner    Mailbox2 Mailbox2[10103]: Deleting message 'test issue subject line' without processing in order to avoid creating duplicate issues/comments. This message has already been partially processed, associated issue key: TEST-18

This is a known JIRA bug and may be fixed in a future version: https://jira.atlassian.com/browse/JRA-41831 (fixed: 7.0.2+) Duplicate issues creation fails - Creating multiple issues by one Email

JIRA fires Issue Assigned event for newly created Issues

https://confluence.atlassian.com/display/JIRAKB/JIRA+fires+Issue+Assigned+event+for+newly+created+issues

Issues aren't created

If you see the following error message in auditing drill down, it could relate to the choice of custom field for Email > Addressee Processing : Assign non jira-user Email to Text CustomField .  This field really needs to be a Multi-Line Text Custom Field type, because it doesn't take many email address to fill a 255 character single line field.  And this message will be shown in that case.  JEMH 1.7.24+ will contain a Profile advisory check for this scenario.  The reason JEMH doesn't 'only' show Multi-line fields is that other fields could be capable and its not a huge support problem.


The email did not result in a creation/comment/update. ...

Just upgraded your JIRA?

If you have upgraded your JIRA and are seeing messages like the one below, one possible cause is that you changed the JIRA organisation text when you upgraded. This would make your JEMH licence invalid. Please Contact Us if you suspect that is the case and we will be happy to help you out. For more information on JEMH Licensing, please refer to our JEMH Licensing Page.

As <username> the issue could not be created, see the following wiki page for more about Issue Creation scenarios: https://thepluginpeople.atlassian.net/wiki/display/JEMH/Create+Issues - The IssueInputParameters used during creation were:

Provided Value
fieldValues: [], actionParams<email parameters>...

nFeed causes JEMH editors to break

v5.3.0 of nFeed loads the ACE editor in jira.admin and jira.general contexts.  This affects Ad-Hoc notifications (general context) and all JEMH Admin editors (jira.admin) context.  Current workaround is to downgrade nFeed to 5.2.5 where this wasn't the case, or upgrade to 1.7.20+ where an effort to be compatible in this situation results in the adhoc editor being available, but that, and all JEMH editors do not have full screen edit.

nFeed Custom Field Setup

https://valiantys.atlassian.net/wiki/spaces/NFEED512X/pages/279838721/How+to+set+a+nFeed+field+from+JEMH

Unable to process mails encoded with UTF-7

Java doesn't support UTF-7, there are 3rd party (free) libraries like the Java UTF-7 Charset support project (download).  This ZIP contains ./jutf7-1.0.0/jutf7-1.0.0.jar , the JAR must be extracted, and copied into your JAVA installation folder: JAVA_HOME/jre/lib/ext , a JIRA restart will be required to make UTF-7 support available.

Using Exchange? Got duplicate issues?

If you enable inbound mail logging and see things like:

2014-08-25 00:01:25,891 WARN [PT_Email] atlassian-scheduler-quartz1.clustered_Worker-4 ServiceRunner    Blah Mail Handler IT Helpdesk Mail Handler[10100]: javax.mail.AuthenticationFailedException: AUTHENTICATE failed. while connecting to host 'mail.blah.com' as user 'blah\helpdesk' via protocol 'imaps

The following has been reported to help

-Dmail.imap.auth.plain.disable=true

Upgrades take too long / impact performance

When upgrading JEMH, database tables sometimes need to be updated.  If the upgrade jumps across many versions, potentially many such updates will need to run consecutively, adding delay.  These are one off upgrades and must be allowed to complete.

Minimising delays
mail.mime.multipart.ignoreexistingboundaryparameter=true

The delays are proportional to the data in the database, so customers with high volumes of email will notice this more.  To reduce impact of these delays the following actions can be taken:

  1. Disable auditing and Delete All audit history (no impact to user data).  If you have already upgraded and disabled JEMH part way through the upgrade, you may be in a catch 22 situation.  To remove audit history with JEMH disabled, a low level database table clean up is needed, please see Audit History is too large (below).
  2. Execute a database table content deletion on AO_78C957_NOTIFICATION_HIST (this will remove all Notification History)

Incorrect Message Association through reply

Empty MessageID's in notificationinstance.messageid cause replies with an empty reply-to: to be associated with issues incorrectly.  JEMH and Atlassian mail handlers suffer this problem historically. 

Solution part 1

JEMH 1.7 / 1.6.x latest maintenance will check messageID's for a value prior to using for message association (pre-emptying the problem)

Solution part 2

JEMH 1.7.x /1.6.x latest maintenance will check for replies with an empty reply-to: fields, and not it for a lookup in that case

Database fix

A resolution is to simply remove rows with empty values, combined with Solution part 1 will be enough to stop recurrence.

delete from notificationinstance where messageid='';

Why Attachments are sometimes missing from notifications driven by interactive comments/attachment uploads

When users add attachments 'with a comment' the attachments are added on the fly, timestamped as they are added.  If a user adds a few attachments, the timestamps are spread.  If a user adds a long issue or takes a coffee break before submitting the comment, the final ISSUE_UPDATED event fired due to the comment could be minutes apart from the related attachment timestamps (comments don't track attachments added at the same time).  JEMH uses an hour time-window to correlate that an added attachment is related to the 'event' that is driving the notification.  It works most of the time, but not in some situations where a user may add an attachment and then wait a while before sending.

The only workarounds are to enable "Require a comment to notify" in Event Listener, or to educate interactive users to type the comment in first so that there is a higher probability of correct correlation.

For now, there is nothing else that can be done, an issue has been logged ( https://jira.atlassian.com/browse/JRA-43448 ).

XML Profile Export not working

Its been noted that the profile export fails to 'produce' the XML output.  This has been traced to the Field Security Plugin (see  JEMH-1212 - Getting issue details... STATUS ) that needs to be upgraded to JFS 1.4.15_52 (available at downloads page), or disabled until the export has completed

Unable to get attachments, got an IO error: Expected ';', got ...

JEMH will not be able process emails that do not conform the the http://www.ietf.org/rfc/rfc2183.txt specification, and will complain with hintOgrams (if enabled):

Hint #1:
--------
Message : Unable to get attachments, got an IO error: Expected ';', got ","
Hint Detail : com.javahollic.jira.emh.engine.FieldProcessorFixer.fixupAttachments():1031
Caused By : class="javax".mail.internet.ParseException : message=Expected ';', got ","

Atlassian documentation: 

Next Steps: The related attachment was not processed and is not processable.  A manual export of the mail, to text, can allow the formatting issues to be dealt with, and the email re-injected via a TestCase.

Possible workaround:

Configuration doesn't 'save'

When saves "don't work" this is a general indicator that a field you have entered (should I say crammed!) has exceeded the schema expectations. Its a little annoying to trace, but do this:

1. Uninstall / reinstall JEMH (this will flush the 'cache' of ActiveObject database records held in memory)
2. Edit a boolean form field somewhere, save.

The change should persist. Now, make (and save) one configuration change at a time. If you are storing 'large' quantities of text, for example in catchmail, it may need increasing. JEMH once thought 255characters was enough, but has since made these fields (and many more) unlimited text now. Schema changes aren't possible, so just need be be triaged through support as/when it arises. In this situation you can safely extend the schema, as described here:

The following Configuration fields are now unlimited text, contrast this fields you are changing:

  • CreateUsersEmailWhitelist
  • CreateUsersEmailBlacklist
  • CatchEmailAddress
  • JemhAddresseeRegexps
  • SubjectCleanupRegexps
  • BlacklistedAttachmentTypes
  • WhitelistSenders
  • GreylistSubjectRegexps
  • GreylistEmailBodyRegexp
  • GreylistSenders
  • BlacklistSenders
  • BlacklistRecipients

Updating your schema through a lossless conversion from char (255) to text will enable unlimited text to be entered.

Example:

alter table AO_78C957_CONFIG alter column CREATE_USERS_EMAIL_BLACKLIST text;


Dropping JEMH tables and removing JIRA_HOME/data/jemh still not enough to reinstall from blank

Oracle also has SEQuence tables that need to be cleared, for example:

DROP SEQUENCE JIRA.AO_78C957_ALIASES_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_AUDITCONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_AUDITEVENTS_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_AUDITHINT_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_AUDITMETA_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_AUDITMETA1808070293
GO
DROP SEQUENCE JIRA.AO_78C957_AUDITMETA2102932222
GO
DROP SEQUENCE JIRA.AO_78C957_AUTOLABEL480471400
GO
DROP SEQUENCE JIRA.AO_78C957_AUTOLABELCONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_AUTOLABELSUBS_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_BLACKLISTING_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_CERTCONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_CFDEFAULT_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_COLONSUFX1973341390
GO
DROP SEQUENCE JIRA.AO_78C957_CONFIG_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_FIELDPROC_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_LDAPCONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_LSNR_CONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_LSNR_JPRO1882553326
GO
DROP SEQUENCE JIRA.AO_78C957_LSNR_PROJ_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_LSNR_PROJ488737470
GO
DROP SEQUENCE JIRA.AO_78C957_NAGCONFIG_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_NAGPHRASE_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_NAGPHRASESET_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_NOTIFICAT1268048665
GO
DROP SEQUENCE JIRA.AO_78C957_PGPCONFIG_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_PRJDOMMAP_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_PRJGRPMAP_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_PROFILE_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_PROJCONFIG_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_REGEXPPROCCNF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_REGEXPPROCMAP_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_SUPPORT_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_TEMPLATESET_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_TESTCASE_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_TRANSPORTS_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_TWITTERCREDS_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_WEBFORMCONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_WEBFORMITEM_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_WUFOOCONF_ID_SEQ
GO
DROP SEQUENCE JIRA.AO_78C957_WUFOOFORM1291342826
GO
DROP SEQUENCE JIRA.AO_78C957_WUFOOFORMS_ID_SEQ
GO

CommentQtyOrSizeFilter: MessagingException, failed to get email body: Missing start boundary

Symptom

JEMH Audit History can show some mails as unprocessed, with a filtration message:

"The message was filtered 
CommentQtyOrSizeFilter: MessagingException, failed to get email body: Missing start boundary" 
Filter Name: Comment size or number limit filter

Explanation

This happens because some emails are not correctly formatted, and contain missing mime/multipart boundaries. The JEMH Audit History stored email is a re-serialisation of the mail, the process of which actually generates a 'valid' email which could be re-processed successfully (convert it to a JEMH Test Case via the Audit History operations, edit the Test Case to pick the right profile, run the Test Case).

For background on the problem see: http://stackoverflow.com/questions/2043792/missing-start-boundary-exception-when-reading-messages-with-an-attachment-file

The Fix

The fix requires an environment flag to tell Javamail (the library JIRA and JEMH rely on for email processing) to allow this condition.  Updating JIRA environment variables is documented at: https://confluence.atlassian.com/display/JIRA/Setting+Properties+and+Options+on+Startup 


-Dmail.mime.multipart.ignoreexistingboundaryparameter=true

This has been verified through a support case.

Alternatively, the email could use broken syntax

The reason could  be the format of the mime multipart separator header:

Message-ID: <201409221917002963505@55.blah.xx.yy>
Content-Type: multipart/alternative;
	boundary="------=_001_NextPart274015426730_=----"
MIME-Version: 1.0

The specification ( http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html ) defines the grammar that can be used for this:

...
Overall, the body of a multipart entity may be specified as follows:
multipart-body := preamble 1*encapsulation 
               close-delimiter epilogue 

encapsulation := delimiter CRLF body-part 

delimiter := CRLF "--" boundary   ; taken from  Content-Type 
field. 
                               ;   when   content-type    is 
multipart 
                             ; There must be no space 
                             ; between "--" and boundary. 

close-delimiter := delimiter "--" ; Again, no  space  before 
"--"

The fun part is that this mail client has used hyphens as the multipart separator which javamail (correctly) is interpreting the 'next' multipart separator as the closing separator, which kind of breaks things.

You can fix this manually by changing the separator (everywhere) to:

--xxxx=_001_NextPart274015426730_=xxxx

Data truncation: Data too long for column 'TO_ADDRESS' at row 1

Symptom

2012-08-10 09:35:23,042 ERROR jira ticket import QuartzWorker-0 ServiceRunner jira ticket import jira ticket import10310: Exception: null
java.lang.reflect.UndeclaredThrowableException
at $Proxy1655.save(Unknown Source)
at com.javahollic.jira.emh.service.EnterpriseMessageHandlerImpl.handleMessage(EnterpriseMessageHandlerImpl.java:316)
at com.javahollic.jira.emh.service.EnterpriseMessageHandlerProxy.handleMessage(EnterpriseMessageHandlerProxy.java:43)
at com.atlassian.jira.service.services.mail.MailFetcherService$1.process(MailFetcherService.java:361)
at com.atlassian.jira.service.services.mail.MailFetcherService$MessageProviderImpl.getAndProcessMail(MailFetcherService.java:264)
at com.atlassian.jira.service.services.mail.MailFetcherService.runImpl(MailFetcherService.java:349)
at com.atlassian.jira.service.services.file.AbstractMessageHandlingService.run(AbstractMessageHandlingService.java:250)
at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:61)
at com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:47)
at org.quartz.core.JobRunShell.run(JobRunShell.java:195)
at com.atlassian.multitenant.quartz.MultiTenantThreadPool$MultiTenantRunnable.run(MultiTenantThreadPool.java:72)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'TO_ADDRESS' at row 1

Cause

This error occurs if the addressee list is greater than 255 characters. This has been fixed in current release (1.2.36+) however, the update will not occur in the background and a manual change is required.

Resolution

Option 1
  1. On the Audit History screen, hit the Delete All Events button
  2. Uninstall the JEMH plugin (no configuration will be affected)
  3. Get a database administrator to drop the following tables
    • AO_78C957_AUDITHINT
    • AO_78C957_AUDITEVENTS
  4. Install JEMH 1.2.41+, the tables will now be automatically created with types appropriate for your database.
  5. Trigger a loading of the JEMH plugin (and creation of missing tables) through accessing the Audit History screen
  6. Verify that the AO_78C957_AUDITEVENTS table CC_ADDRESS column is of type 'TEXT'/unlimited characters.
  7. Run another Test Case with a long addressee list should now be processed as expected, eg:

    MIME-Version: 1.0
    Received: by 10.223.112.12 with HTTP; Sat, 18 Jun 2011 22:42:26 -0700 (PDT)
    Date: Sun, 19 Jun 2011 17:42:26 +1200
    Message-ID: <BANLkTinB1mfSh+GwOXGNWoL4SyDvOpdBoQ@mail.gmail.com>
    Subject: This is a starting email template, update as required
    From: "Andy Brook" <andy@localhost>
    To: notest@localhost, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@place.com, bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb@place.com, cccccccccccccccccccccccccccccccccccccccccccccc@place.com, dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd@place.com, eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee@place.com, fffffffffffffffffffffffffffffffffffffffffffffffffffffff@place.com
    Content-Type: text/plain; charset=UTF-8

    some text

Option 2
  1. With knowledge of your database, it is also possible to update the datatype of TO_ADDRESS column of the AO_78C957_AUDITEVENTS table, updating from a limited 255character type to an unlimited varchar/text type as appropriate (updating the CC_ADDRESS and EMAIL_SUBJECT as well, to fix them too).
Mysql
alter table AO_78C957_AUDITEVENTS change TO_ADDRESS TO_ADDRESS text;
alter table AO_78C957_AUDITEVENTS change CC_ADDRESS CC_ADDRESS text;
alter table AO_78C957_AUDITEVENTS change EMAIL_SUBJECT EMAIL_SUBJECT text;
Postgres
alter table "AO_78C957_AUDITEVENTS" alter column "TO_ADDRESS" type text;
alter table "AO_78C957_AUDITEVENTS" alter column "CC_ADDRESS" type text;
alter table "AO_78C957_AUDITEVENTS" alter column "EMAIL_SUBJECT" type text;
SQLServer
alter table AO_78C957_AUDITEVENTS alter column TO_ADDRESS text;
alter table AO_78C957_AUDITEVENTS alter column CC_ADDRESS text;
alter table AO_78C957_AUDITEVENTS alter column EMAIL_SUBJECT text;
Option 3
  1. Ignore the problem. As of 1.2.41, data in these fields will be shortened to fit, some addressee information will be lost as a result.

Notification history update problem:  ERROR: value too long for type character varying(255)

Similar to the last issue, older instances that had the schema created will have char(255) as a column type which isn't enough for some situations.  columns again need converting to text types;

  • AO_78C957_NOTIFICATION_HIST.JIRA_ADDRESSEE_USERS
  • AO_78C957_NOTIFICATION_HIST.NON_JIRA_ADDRESSEE_USERS
  • AO_78C957_NOTIFICATION_HIST.SUBJECT

Routes to accomplish this are also the same as above, either:

  1. Option1: Uninstall JEMH, Drop the AO_78C957_NOTIFICATION_HIST table, reinstall JEMH (will recreate tables)
  2. Option 2: Make the direct SQL calls appropriate to change the above column types to text.

MYSQL exception - Caused by: java.sql.SQLException: Incorrect string value: '\xD9\x8A\xD8\xB1\xD8\xAC...' for column 'EXCEPTION' at row 1

Cause

MySQL does not always support 4 byte characters

With the standard character set (utf8), MySQL does not support 4-byte UTF-8 characters (for example: 😊 or 'dogpile' 💩. – it saves here because JIRACloud doesnt use MySQL!). This means that some characters simply cannot be stored, and will be rejected by JIRA. In this case there isn't much that can be done, the character is legal but the database cannot support it.

References

Symptoms

  • JEMH fails to process email, possibly preventing other emails from being processed
Caused by: java.sql.SQLException: Incorrect string value: '\xD9\x8A\xD8\xB1\xD8\xAC...' for column 'EXCEPTION' at row 1

Resolutions

  1. See Handling UTF-8 multi-byte characters with a MySQL database for some steps that can be taken to work around this
  2. Migrate to a database that is known to fully support 4-byte characters out-of-the-box, like PostgreSQL
  3. As of MySQL 5.7, it may be possible to use the utf8mb4 charset with JIRA 7.3.  We cannot personally vouch for this and so caution is advised: https://confluence.atlassian.com/jirakb/jira-does-not-work-with-emoji-4-byte-characters-429919955.html
  4. Convert the column being complained about to UTF-8. For example, updating the AUDITEVENTS table EXCEPTION column to UTF-8 in the JIRA database would be done with:
ALTER TABLE `jira`.`AO_78C957_AUDITEVENTS` MODIFY COLUMN `EXCEPTION` TEXT  CHARACTER SET utf8 COLLATE utf8_general_ci DEFAULT NULL;

Configuration screen won't save updates

Cause

The use of these fields exceeded expectation, most of the text entry fields had at one point a 255 character limit set, e.g. blacklist senders regular expression. If a save was attempted that exceeded this limit, the save failed. Unfortunately, whilst the update failed, the configuration entity object that contained this value got 'left' with the larger value, meaning that any future changes would not work until that previous field value was fixed.

Current builds now have marked the specific fields commonly causing this problem as unlimited length, but unfortunately, such changes are not yet reflected automatically into a pre-existing installation.

Workaround

Locate the text field previously edited, look for a value that is greater than 255 characters, fix it so its less than that. The save, and future changes should now work.

Resolution

The schema needs to be updated. As the AO layer used to access the database doesn't actually reflect UNLIMITED length if the schema already exists, a simple tweak is to change datatype on a per-column basis, given the change is from a 255 character field to unlimited, no data will be lost.

With no data changes going on, this change should be transparent to JIRA, previously failing saves should now work.

Depending on your revision there are two tables that have caused problems:

  • AO_78C957_AUDITEVENTS, containing audit history, large addressee lists, this is listed above (Data truncation: Data too long for column)
  • AO_78C957_CONFIG, contains core configuration fields

AO_78C957_CONFIG fields

  • BLACKLIST_SENDERS
  • BLACKLIST_RECIPIENTS
  • BLACKLISTED_ATTACHMENT_TYPES
  • BODY_DELIMITER_REGEXPS
  • CREATE_USERS_EMAIL_BLACKLIST
  • CREATE_USERS_EMAIL_WHITELIST
  • CATCH_EMAIL_ADDRESS
  • GREYLIST_SUBJECT_REGEXPS
  • GREYLIST_SENDERS
  • GREYLIST_EMAIL_BODY_REGEXP
  • JEMH_ADDRESSEE_REGEXPS
  • SUBJECT_CLEANUP_REGEXPS
  • WHITELIST_SENDERS

Mysql Script

(info) for a Schema called jira514 (set it to the default in tools like emma), update this to reflect your deployment:

alter table AO_78C957_AUDITEVENTS change TO_ADDRESS TO_ADDRESS text;
alter table AO_78C957_AUDITEVENTS change CC_ADDRESS CC_ADDRESS text;
alter table AO_78C957_AUDITEVENTS change EMAIL_SUBJECT EMAIL_SUBJECT text;

alter table AO_78C957_CONFIG change BLACKLISTED_ATTACHMENT_TYPES BLACKLISTED_ATTACHMENT_TYPES text;
alter table AO_78C957_CONFIG change BLACKLIST_SENDERS BLACKLIST_SENDERS text;
alter table AO_78C957_CONFIG change BLACKLIST_RECIPIENTS BLACKLIST_RECIPIENTS text;
alter table AO_78C957_CONFIG change BODY_DELIMITER_REGEXPS BODY_DELIMITER_REGEXPS text;
alter table AO_78C957_CONFIG change CREATE_USERS_EMAIL_BLACKLIST CREATE_USERS_EMAIL_BLACKLIST text;
alter table AO_78C957_CONFIG change CREATE_USERS_EMAIL_WHITELIST CREATE_USERS_EMAIL_WHITELIST text;
alter table AO_78C957_CONFIG change CATCH_EMAIL_ADDRESS CATCH_EMAIL_ADDRESS text;
alter table AO_78C957_CONFIG change GREYLIST_SUBJECT_REGEXPS GREYLIST_SUBJECT_REGEXPS text;
alter table AO_78C957_CONFIG change GREYLIST_SENDERS GREYLIST_SENDERS text;
alter table AO_78C957_CONFIG change GREYLIST_EMAIL_BODY_REGEXP GREYLIST_EMAIL_BODY_REGEXP text;
alter table AO_78C957_CONFIG change JEMH_ADDRESSEE_REGEXPS JEMH_ADDRESSEE_REGEXPS text;
alter table AO_78C957_CONFIG change SUBJECT_CLEANUP_REGEXPS SUBJECT_CLEANUP_REGEXPS text;
alter table AO_78C957_CONFIG change WHITELIST_SENDERS WHITELIST_SENDERS text;
commit;

Postgresql

(info) Postgres likes to lower case everything, you'll need to quote the table and columns that AO has created.

alter table "AO_78C957_CONFIG" alter column "TO_ADDRESS" type text;
alter table "AO_78C957_CONFIG" alter column "CC_ADDRESS" type text;
alter table "AO_78C957_CONFIG" alter column "EMAIL_SUBJECT" type text;

alter table "AO_78C957_CONFIG" alter column "BLACKLIST_SENDERS" type text;
alter table "AO_78C957_CONFIG" alter column "BLACKLIST_RECIPIENTS" type text;
alter table "AO_78C957_CONFIG" alter column "BLACKLISTED_ATTACHMENT_TYPES" type text;
alter table "AO_78C957_CONFIG" alter column "BODY_DELIMITER_REGEXPS" type text;
alter table "AO_78C957_CONFIG" alter column "CREATE_USERS_EMAIL_BLACKLIST" type text;
alter table "AO_78C957_CONFIG" alter column "CREATE_USERS_EMAIL_WHITELIST" type text;
alter table "AO_78C957_CONFIG" alter column "CATCH_EMAIL_ADDRESS" type text;
alter table "AO_78C957_CONFIG" alter column "GREYLIST_SUBJECT_REGEXPS" type text;
alter table "AO_78C957_CONFIG" alter column "GREYLIST_SENDERS" type text;
alter table "AO_78C957_CONFIG" alter column "GREYLIST_EMAIL_BODY_REGEXP" type text;
alter table "AO_78C957_CONFIG" alter column "JEMH_ADDRESSEE_REGEXPS" type text;
alter table "AO_78C957_CONFIG" alter column "SUBJECT_CLEANUP_REGEXPS" type text;
alter table "AO_78C957_CONFIG" alter column "WHITELIST_SENDERS" type text;
commit;

SqlServer

alter table AO_78C957_AUDITEVENTS alter column TO_ADDRESS text;
alter table AO_78C957_AUDITEVENTS alter column CC_ADDRESS text;
alter table AO_78C957_AUDITEVENTS alter column EMAIL_SUBJECT text;

alter table AO_78C957_CONFIG alter column BLACKLIST_SENDERS text;
alter table AO_78C957_CONFIG alter column BLACKLIST_RECIPIENTS text;
alter table AO_78C957_CONFIG alter column BLACKLISTED_ATTACHMENT_TYPES text;
alter table AO_78C957_CONFIG alter column BODY_DELIMITER_REGEXPS text;
alter table AO_78C957_CONFIG alter column CREATE_USERS_EMAIL_BLACKLIST text;
alter table AO_78C957_CONFIG alter column CREATE_USERS_EMAIL_WHITELIST text;
alter table AO_78C957_CONFIG alter column CATCH_EMAIL_ADDRESS text;
alter table AO_78C957_CONFIG alter column GREYLIST_SUBJECT_REGEXPS text;
alter table AO_78C957_CONFIG alter column GREYLIST_SENDERS text;
alter table AO_78C957_CONFIG alter column GREYLIST_EMAIL_BODY_REGEXP text;
alter table AO_78C957_CONFIG alter column JEMH_ADDRESSEE_REGEXPS" text;
alter table AO_78C957_CONFIG alter column SUBJECT_CLEANUP_REGEXPS text;
alter table AO_78C957_CONFIG alter column WHITELIST_SENDERS text;
commit;

Audit History is too large

If the inbound mail volume is significant, history can build up quickly. The retention period can introduce significant delays..

This is being tracked at [JEMH-1067]

Interim solution is to delete the history and set a lower threshhold for retention.  Drop tables when JIRA is DOWN so that they are automatically recreated when JIRA comes UP.

  1. Delete Audit Data

    SQL

    File Data

    Example for Postgresql, other databases should be similar.

    DELETE FROM "AO_78C957_AUDITMETA_DOMAIN";
DELETE FROM "AO_78C957_AUDITMETA_PROJECT";
DELETE FROM "AO_78C957_AUDITMETA";
DELETE FROM "AO_78C957_AUDITHINT";
DELETE FROM "AO_78C957_AUDITEVENTS";

    Delete the folder JIRA_HOME/data/jemh/auditmail

  2. Reset the retention period to 1 day

Cannot install license: name is already used by an existing object

This can happen when a previous installation has been wiped (all AO_78C957_* tables) and the JIRA_HOME/jemh folder removed, but licenses still fail due to old sequences being present. All these should be removed too, then a uninstall/reinstall cycle of the plugin should kick everything back into being created. Eg, see https://studio.plugins.atlassian.com/browse/JEMH-1075

Comment Headers have nulls in

If you see strange template output as a comment header, this is an indication that the export/import of the template, which kept the ID's of the templates used on serverA have matched a template on serverB (but is most likely not to be the same template. Migrate templates (1.3+) and edit configuration to match the correct template. see https://studio.plugins.atlassian.com/browse/JEMH-1128 https://studio.plugins.atlassian.com/browse/JEMH-1128

null created null:
-------------

             Summary: $issue.summary
                 Key: ${issue.getKey()}
                 URL: http://floater:8080/browse/${issue.getKey()}
             Project: $issue.getProject().getString("name")
          Issue Type: $issue.getIssueTypeObject().getNameTranslation($i18n)

Test Cases / Blacklisting image previews / Auditing files are absent after a JIRA backup/restore to another server

JEMH configuration and audit meta data is all stored in the database using Active Objects so as to be included in the XML backup. JEMH also has many resources on-disk that are not backed up and will not be restored, these resources are:

  • Test Cases
  • Blacklisting (uploaded) preview files
  • Auditing supporting emails.

Migration of Test Cases can only be done one by one currently (@1.3), requiring a new Test Case to be created, and a specific email file picked through the file browser button available during edit.

Blacklisting files can be manipulated to appear in the right place, however care must be taken, as getting the filename ID wrong, will be confusing to the user as the wrong image may then be associated with a description /hash.

Audit history cannot be migrated, is not suitable for long term reference and is meant to provide transitory reference only. Best option is to hit Auditing > Delete ALL to flush all database data to start from blank.

Non-latin character support on Microsoft SqlServer

Unfortunately there is a bug in the Active Objects layer that JEMH uses to store data (https://ecosystem.atlassian.net/browse/AO-386).  Effectively, this means that non-latin character support using SQLServer is not possible.  Symptoms of this will be an inability to select correctly displayed non-latin text in priorities/issue types etc, but on save, the non-latin characters are replaced with (from evidence so far) latin equivalents.  This is slated for being fixed in JIRA 7, however the process for apply this is not automatic.  Atlassian (as per AO-386) have advised that a full XML export and import into a JIRA 7 instance is the way to convert the data.

Watcher Custom Field for JIRA Plugin

The Watcher Custom Field for JIRA plugin is incompatible with JEMH, some customers have reported various issues caused by the behaviour of this plugin due to the impact it has on JIRA issue validation and therefore JEMH issue creation. 

Possible workaround:

When using this plugin, do not name the custom field created by the plugin "watchers" as this will cause incompatibilities with JEMH's built in watcher behaviour. Customers have found that naming the custom field with a name other than "watchers" prevents JEMH incompatibilities but your mileage may vary. 

IOException/Mail stuck after adding and then immediately deleting an attachment

While waiting for a notification that contains an attachment to be sent, if you delete any of the attachments included in the notification before it is sent will result in the notification being lost (not sent) and will result in an IOException message being displayed in the atlassian-jira-outgoing-mail.log. This includes the scenario of having Require Comment to Notify enabled in the Event Listener, if any of the attachments in the notification are deleted before the notification is sent, this will result in the loss of the entire notification.

Error 500 - Filter execution threw an exception after running a test case.

If you receive an error 500 message after running a test case to add a comment on an issue in a JSD project and you have Adaptavist ScriptRunner for JIRA installed, ensure that there are no errors in any of the script fields that you you have configured as this has been found to cause this problem.

Blacklist attachments missing after JEMH upgrade

In the event of blacklist attachment entries being missing after upgrading JEMH, the database upgrade scripts might have not ran correctly and running the following commands against your database will restore the entries.


List all blacklisting entries

The missing entries will have the column BLACKLIST_TYPE set as NULL.

SELECT * FROM "AO_78C957_BLACKLISTING";


Reset subject blacklisting types

UPDATE "AO_78C957_BLACKLISTING" SET "BLACKLIST_TYPE"='subject' WHERE "SUBJECT_REGEXP" IS NOT NULL;


Reset attachment blacklisting types

UPDATE "AO_78C957_BLACKLISTING" SET "BLACKLIST_TYPE"='fingerprint' WHERE "ATTACHMENT_HASH" IS NOT NULL;


Verify no untyped entries remain
All entries will have either subject or fingerprint set in the BLACKLIST_TYPE column.

SELECT * FROM "AO_78C957_BLACKLISTING" WHERE "BLACKLIST_TYPE" IS NULL;

Email client shows encoded attachment name instead of decoded file name

JIRA 7 and newer uses a version of JavaMail (a framework for email reading/writing) which has changed its default handling of encoded email parameters to conform with RFC 2231.  Here is an example showing the same attachment, sent using JavaMail in JIRA 6.4 and 7.0 respectively:

JavaMail used in JIRA 6.4.x and olderJavaMail used in JIRA 7.0.x and newer
Content-Type: text/plain 
Content-Transfer-Encoding: 7bit 
Content-ID: <55228d63-8105-49eb-a841-57e812d6a25c> 
Content-Disposition: attachment;  
    filename="=?UTF-8?B?4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ?= 
 =?UTF-8?B?4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ?= 
 =?UTF-8?B?4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQLnR4dA==?="
Content-Type: text/plain 
Content-Transfer-Encoding: 7bit 
Content-ID: <c8890c7d-e24a-407b-a94a-fa1127eb5cb9> 
Content-Disposition: attachment;  
    filename*0="=?UTF-8?B?4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ?= 
 =?UTF-8?B?4pqQ4";  
    filename*1="pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ?= 
 =?UTF-8?B?4pqQ4pqQ4pqQ4pqQ";  
    filename*2="4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQ4pqQLnR4dA==?="


Some email clients (including Gmail and Outlook) unfortunately do not conform to RFC 2231.  This means that when JEMH sends attachments in emails that have particularly long names including non-ASCII characters, they are not shown and instead the encoded string is displayed instead.

This problem can be worked around by setting the below Java property on JIRA startup in order to disable JavaMail's incompatible (but technically correct) encoding of parameters.