Some further fixes relating to Internal JSD comments, also:

• JEMHC-1831 : Notification mapping email users audience custom fields not saving correctly

• JEMHC-1793 : We now tag images generated by JEMHC to enable faster detection on the way in (rather than hashing)

• JEMHC-1811 : Slack notifications from JEMHC to private channel

• JEMHC-1829 : Macro content (pasted in the description) is getting parsed in outbound change notification (we needed to quote customer content to stop it being ‘parsed’)

• JEMHC-1833 : NPE problem we introduced in 1.3.14 relating to SVG processing

• JEMHC-1834 : Fixed User Lookup strategy ‘run as user’

About the workaround user. New instances are getting the JEMHC ‘addon user’ created with a special group membership that grants BROWSE_USER (means JEMHC can search for users by email address), so this means new customers don’t need the workaround user. Historic customers do still need it because Atlassian have not patched existing app users groups. I have logged this case with Atlassian Support (no, you cant see it : AMKTHELP-14055, the original issue was https://ecosystem.atlassian.net/browse/AC-1014 . Hopefully Atlassian will patch existing users to simplify this area.

What

We will be taking JEMHC offline in order to upgrade the underlying database. We do this periodically to get performance and security updates.

When

This will be done at 0700 GMT on SUN 16 DEC 2018 to minimize impact to most customers.

Impact

• for safety, we will pause mail retrieval and event processing until the upgrade is complete

• there may be short periods during database db switch-over where Webhooks sent by Jira instances will be lost

This is the second release related to upcoming Atlassian GDPR Changes we are required to comply with. In this release we have upgraded all default system Templates, Themes and Macros to be GDPR friendly. The new templates won’t look for user data (username, display name, email address, etc) in the stored event context anymore. The data will be retrieved at “rendering time” based on the “accountId” stored in the event (like user fields, changelogs, etc.).

If you have custom templates/macros/themes don’t worry (too much). We have migrated custom template detecting and replacing old pieces of template with new ones. This is not a perfect migration so you would need to revisit your templates/macros/themes. Also personal information in events is still kept for now, old template should work.

Below are examples of the changes made automatically. Please review your own custom Templates and replace any variants that accessed user data through legacy methods:

#set ($fields = $context.issue.fields)
#if ($fields.assignee.name.textValue())
  $fields.assignee.name.asText()
#else
  Unassigned
#end

#set ($assigneeAccountId = $fields['assignee'].accountId.asText())
#set ($assigneeVal = $jemhUtils.getUserDescription($assigneeAccountId))
#if ($!assigneeVal)
$jemhUtils.setFieldRendered() $assigneeVal
#else
(cant get assignee)
#end

If you notice that your emails are not displaying the information correctly (e.g. macro content is rendering) or you are having problem migrating custom templates, please contact support@thepluginpeople.com referring the problem and your host url.

Next steps

In the near future, we will allow customers to opt in to Personally Identifying Information (PII) removal from Events and Preview Context. This will test that your custom templates are really and truly getting personal information at runtime and not from the event. Any “event.user.displayName” left behind would not be resolved.

Around March when Atlassian deprecation notice finishes, JEMHC will start trimming out all personal information from events. You will want to have validated all your custom templates render correctly and perform any manual replacements that could not be done automatically, before that time.

Other fixes

Some other fixes we have released in this version:

• JEMHC-1825 - Getting issue details... STATUS

• JEMHC-1817 - Getting issue details... STATUS

• JEMHC-1822 - Getting issue details... STATUS

• JEMHC-268 - Getting issue details... STATUS

In order be compliant with the new GDPR rules, Atlassian requires app providers to migrate remove and/or report private data stored outside of Atlassians control (i.e. stored in the JEMHCloud Database).

JEMHCloud has historically kept user information that is now considered private. The information JEMHCloud stored includes usernames (necessary for inbound and outbound processing) and other information for event handling, auditing and troubleshooting. The Plugin People have not and will not use/expose any such personal information for other use.

In the last few weeks, The Plugin People team have worked to reduce private data stored by JEMHCloud to report the account ids of users that JEMHCloud keeps for auditing to Atlassian.

A big thanks to Fernando Boucquez (Deactivated) for his efforts here!

If you notice any problems with inbound issue creation or outbound notification, please contact support@thepluginpeople.com referring the problem and your host url.

High level summary

PII : Personally identifiable information (derived from an Atlassian User Profile)

What we did

• We have migrated all static configuration (referring usernames) into GDPR compliant accountId’s where possible.

• Users that could not be found (perhaps they were deleted) have been replaced with USER_REMOVED_FOR_GDPR so you can easily identify and update

• The outbound mail history (if enabled) has had its data purged, so that at this point, as such data is created, we track the accountId’s of the individuals involved, such that we can be driven by user profile privacy settings.

• We’ve implemented the necessary reporting structure that is required by Atlassian for GDPR compliance.

What we still have to do

• Our default notification templates need to migrate to using accountId, with helper methods to dynamically resolve underlying Name and Email.

What you will need to do

• Once we have implemented template support for accountId, customers will be requested to manually migrate any custom templates to make use of accountId. Atlassian will remove the username and email address values from Webhook events used by the templates in MAR 2019. We plan to filter that data out sooner, date TBD.

Detail

Data Migration detail

The migration steps that will be taken:

• Usernames or user keys necessary for user reference may contain personal information and have been migrated to the new and agnostic Atlassian ids or accountId's.

• Event audit will keep user information for now. The migration will extract the related account ids in order to notify Atlassian the information stored. In the future, personal information will be removed from events but this will require system and custom template migration. The migration path of custom templates will be published in the near future.

• Inbound message's reports are purged during the migration as they may contain personal information. New reports will not contain personal information.

• Outbound message's reports and emails during the migration are purged as they may contain personal information. JEMHCloud will record the accountId's of new sent messages so they can be reported to Atlassian as requested.

The Plugin People will automatically migrate 95%+ of the data but there are some scenarios that you would need to migrate the configuration manually. If the configuration is not migrated, the feature will start failing when Atlassian stops user lookups by user key or username (only by account id will be allowed).

Data Migration Date

We expect to go live with this change over the weekend of 1-2 DEC 2018.

Automated Data Migration

The following migration tasks will be automatically performed:

Ping

• It tests that the host is up running before running the migration.

Profile

• Replaces reporterName and assigneeName to account ids.

• Replaces fieldProcessorUserWhiteList to account ids

• Replaces createdBy, UpdatedBy and auditing user references from user key to account ids.

• Replace default single/multi user picker custom fields values from username/key to account ids

• Removed diff description of profile audits that may contain username

Notification Mappings

• Moves recipient user field (that could be a username or email address) to the user multi-picker if the field is a username. Notification mappings will hold a recipient email address and a static user list independently.

Ad Hoc stored configuration global and per project.

• Replaces the user list in to, cc, bcc from usernames to account ids

Webhook Events

• Replaces the user that performed the action from username to the account id.

• Extracts account ids from the event data and stores them in a db column. This would be used for the Marketplace API report in the next releases. In the future, the personal data will be trimmed out from the event. Personal data will be loaded at runtime when generating emails. So no personal data will be stored in events.

Preview Context

• Account ids from the context are collected for reporting. In the future, personal information trimmed out from existing preview context. New preview context won't have any as the source event will be trimmed when created.

Message Audit Inbound

• Reports are removed (as they probably contain PII derived from user profiles)

Message Audit Outbound

• Reports are removed (as they probably contain PII derived from user profiles)

• Email and recipient data are removed (as they probably contain PII derived from user profiles)

System Notifications

• System emails address are migrated to account ids when the email address belongs to a known user. System admin would have the option to either select users, enter emails addresses or both. The stored emails addresses are not going to be resolved from Jira information. This is the new UI:
  

  

Ac Host

• Replaces the user that installed the addon from userkey to account id.

Handling Missing Usernames

• Usernames that cannot be looked up are replaced by the value 'USER_REMOVED_FOR_GDPR'. These usernames were already broken so proper migration cannot be done and JEMHC is not allowed to keep stored. User would need to patch or remove them accordingly.

Manual Migrations Required

Some configurations will not be updated automatically, they are listed below. We will continue to support usernames/keys as long as Atlassian provide that data. If such user references are not updated, these areas will break in the future.

• User picker in post functions.

• Recipient scripts in notification mappings, ad hoc and post functions

Post functions

Atlassian doesn't not provide a way for apps to retrieve and update post function configurations. They only time apps can read the post-function configuration is when the post functions are actually executed. Even then, the configuration cannot be patched/migrated and stored. A Jira/JEMHCloud admin would need to manually patch existing post function.

• Go to Jira workflow configuration as described here.

• Edit workflows where there are JEMHC Email Notification post functions.

• Update the To: Cc: Bcc: recipient tabs patching broken user pickers. Re-select the users and remove the old usernames.

• 

• Save the post function and the workflow schema.

Recipient scripts

Recipient script is an advance JEMHCloud feature that allows admin to dynamically add recipients to an email/sms/slack notification. How to configure recipient scripts can be found here.

Due to the complexity of the scripts, JEMHCloud cannot automatically migrate those scripts so you would need to do it for us.

• Go JEMHCloud → Notification Mappings

• Edit Notification Mappings with Recipient Scripts.

• Replace lines like:

• $recipientUtils.addUserRecipients("someUserKeyOrName, anotuerUserKey") → $recipientUtils.addUserRecipients("anAccountIdGui, anotherAccountId")

• $recipientUtils.addUserRecipients(user.name) → $recipientUtils.addUserRecipients(user.accountId)

• You can use the User Finder tool in JEMHCloud → Tools → User Finder to resolve the account ids of your users:

  

• Save the recipient script.

You will need to repeat this for pre-configured adhoc notifications and post functions.