Use a TestCase for quick testing

Scenario

Configuration is not doing quite what you want, and sending email/waiting/checking is time consuming. There has to be a better way. There is! JEMH TestCases allow you to trigger processing of a TestCase email with the Profile of your choice.

Precursors

Important Settings

When processing (any) email, JEMH needs to figure out two key bits of information:

  • Is the email something JEMH should process
  • What to do if the sender of the email does not match any registered user

Configuration Review

First, check the Profile Email settings:

  • Bulk email relates to content that may come from a distribution network, eg mailing list, such mail has an email header Precedence: Bulk. JEMH gives you the option to Allow/Ignore(drop) or Forward to the 'forwardUser' (see Notifications config section)
  • There is no specific catchemail value, indicating that all mail will be processed by this profile.
  • There is also no jemhAddresseeRegexp value, this means your JIRA could LOOP. A Regexp value can be as simple as the 'one' email address associated with an inbox, eg: inbox@yourco.com , or if there are multiple to: addresses to be handled, it could be a wildcard, e.g.: .*@yourco.com

Next, check the Profile Project settings:

  • The Fallback Project is the project to use if no other configuration determines it should go elsewhere, use this to ensure that an email ends up somewhere, even if its not quite where you expected.
  • The Fallback Component is used if the target project is the Fallback Project and if no other configuration determines it should go elsewhere, use this to perhaps notify a component owner that the 'default' configuration was used, when it perhaps shouldn't have been.
  • Project auto-assign, when your JIRA allows unassigned issues, perhaps you don't want email to arrive and not be assigned. This option enables JEMH to pick a component owner, if its set, or the Lead, ensuring someone knows.
  • Project Mappings, are how JEMH achieves fine grained control over the routing of messages, and is discussed separately.

Finally, check the Profile User settings:

  • The Default reporter user name will be used if the sender of the incoming email does not match a registered jira user (with or without Right to Use JIRA). If this is NOT specified (and user creation is disabled) there will be no 'reporter' and the mail will be rejected.

Activity

Access the JEMH TestCase Tab via the JEMH Configuration screen:

Click on "Create New":

For now use the default email header, note the Profile selection combo. Hit "Create" to save:

Validate the user exists

For this exercise, ensure that the sender email address matches a JIRA user.

Check the Project Security for the reporter

Checking the user 'andy@localhost', the user can be seen to have the group non-jira-users.

That group should be in the target Projects Roles, or authorization checks will fail.

Strict Security

JEMH can be made to follow the LAW of the JIRA Permission Scheme. In this case, some operations will fail with the default Project Permission Scheme. For example, MANAGE_WATCHER_LIST is by default available only to Administrators, perhaps adding a group such as 'non-jira-users' allows strict JIRA security to be left enabled...

As the Test Case is associated with a Profile, you can execute it with the Green icon

Resulting in the Test Case audit event detail screen:

Speedups

  • Access to the related TestCase and Configuration page is available through the breadcrumb trail
  • From this screen, an F5 browser refresh will cause a re-execution of the test case, so with another window for configuration, testing changes becomes a matter of seconds.

Clicking on the issue key takes us to the issue: