8 - Roadmap

Background

JEMH evolved organically since 2009, adding features as required to solve scenarios asked for by customers.  This led to Profiles being feature rich, but all of it was 'global' to messages processed by that Profile.  When email is processed at scale, the ability to perform per-project configurations shows up limitations of 'gobal' configuration in a Profile.

A few years back we implemented JEMH for Cloud (JEMHC), this gave us the opportunity to structure the configuration in a 'better' way benefiting with hindsight experience from JEMH, in the JEMHC configuration model, there are some profile level settings, but most of the email processing options are contained within Project Mappings (which are matched via Project Mapping Rules or selectively applied during comment for related projects).  Where a Project Mapping does not apply, the Default Project Mapping would apply.  In this way the JEMHC model 'inverts' how the current JEMH Profile is structured.  JEMH needs to move toward the JEMHC Project-Mapping centric model in order to maximize flexibility of one profile, as well as (referred below) enabling devolution of some configuration and features to Project Administrators.

What follows is a summary of the (start!) of the work we see ahead, and a broad plan for how we will approach this.  It's informal and does not form a guarantee any particular feature will be implemented within any particular time frame - we get spiked by some activities such as building out full integration testing and releasing JEMH DataCenter with Marketplace licensing support in 2018.

Profile to Project Mapping feature migration (JEMH-5404)

JEMH is moving slowly toward the JEMHC Project-Mapping centric model:

Responsibility Devolution (JEMH-5403)

Currently JEMHC is only manageable by JIRA System Administrators.  This was historically because one Profile could impact many projects, and exposing the ability for one user to break other projects configurations was not acceptable.  With more configuration being moved into Project-centric Project Mappings, we plan to create Project Admin configurable settings for JEMH, that expose the specific Project Mappings from all Profiles (including the Default Project Mapping) that can then be locally administered by Project Admins.

As part of this work, many other areas of JEMH also need devolution for Project Centric views:

• Subject blacklisting

• Attachment blacklisting

• Auditing 

• Template Sets

• Test Cases 

• Event Listener

• Static Resource 

As part of enabling devolved administration, we also need to implement some new features, specifically Auditing of configuration changes for tractability.

Currently we exposes read-only views of the Event Listener configuration for the given project.

Work Plan

We will need to balance two main paths of work:

a) Profile to Project Mapping feature migration

b) Responsibility Devolution

Backlog