V1.1.70 released

Created by Andy Brook [Plugin People] (Unlicensed)
Last updated: Dec 15, 2015
3 min read

Improvements

  • JEMHC-683 : Add source and translation if any of recipients in reports when sending notification.  Now for a given event, you can track (subject to purging of the event) what events result in what notifications to whom, allowing message volume to be more readily explained.

  • JEMHC-682 : It should not be possible to delete preview contexts if they are referred by template sets.  Now, a warning will be displayed in the toolbar if you delete a preview context and then try to preview with it in an already open TemplateSet.

  • JEMHC-671 : Ability to filter auditing (events, incoming, outbound) per issue key.  Now, its possible to:

    • Filter Events by issue key and project:

    • Filter incoming messages by issue key:

    • Filter outbound messages the same:

  • JEMHC-659 : Reuse email in notification when email content is the same for different recipients.  Now, recipients located through static groups in the Notifications section, and Group custom fields are treated as email users, to be included BCC in the notification to email users (if any/in place of, if none).

  • JEMHC-659 : JEMHC customer license pages need to see what we see regarding licensing status.  Now, the historic license transitions that JEMHC has gone through will be visible to the user

  • JEMHC-653 : Duplicate users accounts can result in a newly registered user still being denied.  Now, the Report will contain details where multiple users are concerned.

  • JEMHC-635 : When doing HMTL conversion, detect when in a style block and ignore content.  Now, some classes of bugs relating to HTML processing of HEAD elements will just not be possible.

  • JEMHC-628 : Migrate legacy Agile rest references to new ones.  Now, JEMHC can support setting issues with JIRA Software specific 'Agile' fields.  Currently this is only possible during create, a bug with Atlassian stops it being possible during comment/update, but should be fixed at some point in the near future.  The Directives page has entries for Epic Label, Epic Link and Sprint.  Several mechanisms are available to nominate an active sprint, and are the same as implemented in JEMH (for JIRA Server).

  • JEMHC-613 : Need a post install landing page.  Now, new installers will be redirected into the Configuration Wizard.

  • JEMHC-611 : Rework generated cid of inline images to work with most mail client including gmail.  

  • JEMHC-535 : Need to support workflow advance.  Now its possible to configure within a Project Mapping (ie scoped to a project), many workflow transitions, further scoped to issue type, with a current Issue Status, to be applied on Create/Comment/Both.  See Use Workflow Auto-Advance. This will allow customer replies to drive a transition automatically.  Below is the configuration that is applied to our JEMHC Default Profile, which means all projects containing (ITIL workflow) Support Requests, will auto-transition via "Action Needed" when external parties reply by email, and will Re-open "Closed" issues on comment via "Reopen" - and optionally add a message about that!

  • JEMHC-295 : Add group custom field support to the JIRA notification mapping participants.  IF you have defined the Workaround User, then group members can be resolved (see https://ecosystem.atlassian.net/browse/ACJIRA-296)

  • JEMHC-221 : Issue Notification Checkbox: Notify initiating user of their actions during update.  Now its possible to not notify an initiating user on update:




Bugs

  • JEMHC-672 : Non-Delivery Email Action default not set.  When JEMHC receives an email 'bounce' indicating a non-delivery, a notification will be sent to the Forward User.  Currently its blank by default.  A Profile update will occur for this.
     

  • JEMHC-657 : Connect Framework url check looks down for all hosts.  We have added some remote detection indicators to 'know' if a customer JIRA instance is running the required Framework services.  It has been found on more than one occasion that problem hosts weren't running core infrastructure and needed a reboot.