Blog from June, 2015

New Features

  • JEMHC-18 JEMHC Postfunction - Support has existed in JEMH (for JIRA Server) for a long time, now this has been added to JEMHC.  The Postfunction effectively allows Ad hoc notifications to be sent to arbitrary recipients in response to workflow transitions.  This notification is an addition to the existing notifications sent by JEMHC in response to user/issue edits.  A configuration How To is on the wiki, see Send post function notifications(info) This required a change to the addon descriptor, you will have to manually Update JEMHC to get this feature via Manage Addons > JEMHC > Update.  In this feature, the Postfunction refers to a defined Ad hoc TemplateSet defined in JEMHC > Notifications > Templates > Template Sets.
  • JEMHC-474 Add auto-complete capability to template editors.  Now, its possible to use CTRL-SPACE to auto complete what is 'available' in the velocity context, and more usefully, what is in the 'webhook payload'.  Some familiarity with the JSONObject structure will be needed, but this should speed up tree navigation when a Preview Context is set on a template.

Bugs

  • JEMHC-475 E-junkie datapack purchase integration broke.   Additional security prevented this working, meaning purchase had to be 'applied' manually via support, now fixed, everything is automatic once more.

Improvements

  • JEMHC-479 HipChat UI text updated in the application and wiki to clarify the difference between Global (system events, eg mail forwarded) and Project (issue events, eg created/comment/update).

What Happened

It seems a recent update to JIRACloud has stopped webhook events for JIRA issue creation/updates - https://jira.atlassian.com/browse/JRA-43836.  I have also raised https://jira.atlassian.com/browse/JRA-43981 to make impact of this issue clear, and offer some suggestions for improving this situation.  If Atlassian provide the capability to test for this, we will !

How to know it applies to your instance

Probably every JIRACloud instance.  This is likely to be a short term issue, however, if you see in JEMHC Auditing > Events, no activity for a long period of time, (esp if you just created a test issue/comment and saw nothing!)  then you are affected.

Impact

This means that issue notifications over the last 24 hours will be lost because JEMHC never got the 'webhook' containing the change data.  Unfortunately, at this time,there is now way to catchup on events, esp, if the problem is on the JIRA end.

Next Steps

Atlassian are rolling out a fix to all instances, it may take a while, if you dont want to wait, log a support ticket at support.atlassian.com

 

Did you know you can Integrate Hipchat with JEMHC?

 JEMHC Can be configured to notify a HipChat room of system level events such as mail forwarded as well as mail received, and sent. This means that you will get validation on the inbound leg of mail received, and soon after, confirmation of outbound notifications (driven by WebHooks). If WebHooks are not enabled in your instance for whatever reason, there will be no event notification to JEMHC, but the HipChat notifications can be used to infer that there could be a problem with your JIRA instance, before too much time passes, and too many events are lost.

Dashboard Gadgets

New in this release are a few Dashboard gadgets (See Install the Dashboard Gadget)

Message / Data consumptionUsage History

Comment Only Mode handling

Previously when in Comment Only mode, JEMHC would Drop messages not relating to an issue (ise would be a crate candidate emaill), now there is a configurable Failure Action to Drop or Forward:

Plan exceeded handling change

Previously, when a Plan was consumed, JEMHC would block further inbound message retrieval but continue to permit any amount of outbound notification.  Now, once a Plan has been consumed, in addition to inbound messages retrieval being blocked, outbound event notifications will only be permitted for a short 'grace' period, allowing up to additional 10% Plan usage before finally stopping.  Plan capacity will be need to continue using JEMHC in either inbound or outbound primary modes!  

Plans?

What are Plans?

Plans are what JEMHC applies to each JIRACloud subscribed instance and represent an allocation of Messages and Data, like a mobile phone 'plan'. Plans are allocated based on the active numbers of JIRA users you have. The reason for the plan is to protect the system from massive throughput, usually due to a misconfiguration / mail loop. Plans are not meant to be a revenue generating vehicle, there are an escape valve for higher volume users!

When users first evaluate JEMHC, the 'Plan' allocated is the smallest one, so that any problems can be ironed out before any 'major' problems occur. Upgrades to 'right size' during eval are available on request.

Plan changes on active subscription

Once your subscription goes active, you're entitled to Plan allocation based on users, sometimes this does't happen, perhaps there hasn't been significant traffic to demonstrate everything is ticking over as you'd expect, it won't cause a problem and can be fixed at any point with a mail to jemhc-support@thepluginpeople.com

Upgrade Options

If you are likely to exceed your Plan, there are two options, DataPacks and PlanUpgrades. Neither are available through Marketplace which does not yet have the concept of volume-related billing. DataPacks give additional capacity on demand with Plan Upgrades being a longer term option, as they are available only on an annual basis.

See App licensing for more details.

Common Questions

Q1. I want unlimited data/traffic.

A1. That's not available, all usage is governed by Plans. All users get a Plan in order to manage overall volume handled by the system, to make sure one user doesn't put undue loading on the system (yes JEMHC is a cloud based horizontally scalable system, but scaling costs) and make sure that increases in message and data handling that require infrastructure scaling can be funded.

Q2. We consumed the Plan, its wrong, it needs right sizing

A2. JEMHC Plans are expected to easily meet 80% of all users needs at each user level and are constantly under review. If you happen to exceed your Plan, its quite possible its because your usage is just higher than most and does not mean Plans need increasing to accommodate!

 

 

JEMHC SSL certificates have now been updated, no downtime, no issues found.

The SSL certificate backing our JEMHC service needs renewing, this will be deployed this SAT, 6th JUNE in quiet time.  No customer action is necessary, and no significant downtime is expected as this should be a near-instant deployment to the AWS Elastic Load Balancer.