Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »


Overview

This guide illustrates what you can expect  when a Fields Mapping is configured on a mapping.

As first, consider that not all fields defined on your JIRA instances are available for a Field mapping  and not all fields mappings around different fields are allowed.

After that, consider that depending by the selected field, the syncing behavior can differ for:

  • event type  (e.g. deletion’s syncing is not allowed for attachment)
  • deepness (e.g. comment’s syncing is propagated at one linking’s level, all other fields propagate syncing  at an indefinite linking’s level)

In particular, you can expect a different behavior for the listed groups of fields:

Furthermore,  you must take in consideration  that the configured Fields Mappings is already active on issue creation as on issue editing, exception made for a few set of fields (Comments, Attachment Assignee and Reporter) on issue creation via the escalate issue post function.

Additionally, the Sync on create parameter allows to configure for a set of field:

  • if the create screen opened via the via Herzum Quick actions button must be pre-populated (Sync on create = True) or not when creating an issue via the Herzum Quick actions button
  • if the issue created via the Escalate issue post function must be populated based on the value on the Source issue.

While on issue editing the sync type both is naturally provisioning, on issue creation and/or linking the add-on behavior follows some established conventions that are going to be detailed for:

  • issue creation and/or linking via Herzum Quick actions
  • issue  creation and linking via Escalate Issue post function.

At last, notice that, in general, you can expect the same behavior for a Local Partnerships as for a Remote Partnership.

This guide explain in detail all mentioned  topics so that you can configure suitable fields mappings.

Fields availability and allowed Mapping

Fields availability

All JIRA default fields are available for a Fields mapping configuration.

Custom fields available for field mapping configuration are: Text Field (single line), Text Field (multi-line) and third party custom fields (e.g. the Tempo "Customer Account" custom field) recognized to be text type.

Fields mappings around different field’s type

From

To

Allowed

Text Field (single line)Text Field (multi line)(tick)

Text Field (multi line)

Text Field (single line)

(tick)

Summary, Description, Custom fields

Affect/Fix Versions

(minus)

Summary, Description, Custom fields

Priority

(tick)

Summary, Description, Custom fields

Assignee

(minus)

Priority

Summary, Description, Custom fields

(tick)

Component

Fix/Affect Versions

(minus)

Fix/Affect Versions

Component

(minus)

Fix VersionsAffect Versions(tick)
Affect VersionsFix Versions(tick)

Assignee

Reporter

(tick)

Reporter

Assignee

(minus)

Component

Summary, Description, Custom fields

(minus)

Fix/Affect Versions

Summary, Description, Custom fields

(minus)

Assignee

Summary, Description, Custom fields

(minus)

Allowable fields  for Sync on create

The sync on create parameter set to True allows to:

  • populate the issue create screen opened on Herzum quick action button
  • populate an issue created via the escalate issue post function.

The mentioned setting is available for mostly of the listed fields available for a field mapping, the only fields not still allowed to have this setting are Attachment Assignee and Reporter.

Attachment’s Syncing behavior 

As first you must be aware that attachment synchronization is based on the attachment file name. So, two files having the same name are considered to be the same.

As consequence of it, an attachment is synced only if a file having the same name doesn't exit already on the target issue.

Notice that sync behavior is the same for Partnerships configured across the same or different source and destination Url/s.

Consider that syncing of attachment deletion is not supported yet.

Depending by the configured sync versus you can expect the syncing behavior described bellow.

Syncing is Both

On adding one or more attachments, they are synced on all the linked issue/s and, if other synchronizations have been configured on the target issue/s, they are propagated again indefinitely.

On issue creation and linking or just linking an existing one via the Quick actions buttons, all attachments are synced in both directions and, if other synchronizations have been configured on the source and/or on the target issue/s, they are propagated again indefinitely.

Syncing is source versus target

On adding one or more attachments on the source issue, they are synced on all the linked issue/s and, if other synchronizations have been configured on the target issue/s, they are propagated again indefinitely.

On issue creation via the Quick actions buttons, all attachments on the source issue are synced on the created/linked issues.

On issue linking via the Quick actions buttons,  attachments are synced on all the linked issue and, if other synchronizations have been configured on the target issue, they are propagated again indefinitely.

Syncing is target versus source

On adding one or more attachments on the target issue, they are synced on all the linked issue/s and, if other synchronizations have been configured on the source issue/s, they are propagated again indefinitely.

On issue creation via the Quick actions buttons, as expected, attachments on the source issue are Not synced on the created issues.

On issue linking via the Quick actions buttons,  attachments on the target issue are synced on all the source issue and, if other synchronizations have been configured on the source issue, they are propagated again indefinitely.

Comment’s Syncing behavior

Main difference between Comments syncing and other field syncing consists of it is performed at one linking’s level.

Apart the mentioned limit, it follows the same behavior described for all other fields in case of Issue creation and/or linking via quick actions buttons or escalate issue post function automatic creation.

Consider that, differently by attachment syncing behavior, the syncing on attachment deletion is supported in addition to add and edit comment syncing.

Notice that the comments added by the user, that are candidates to be synced, are managed by the add-on, so that they can be associated to the synced comment created by the system, by following the following convention:

  • a comment added by the user includes the following header: Comment synced by HQL (id:<Issue id>) 
  • a comment added by the system includes the following header: Comment synced by HQL (<Partnership Id>: <Issue id>)

Notice that sync behavior is the same for Partnerships configured across the same or different source and destination Url/s.

Depending by the configured sync versus you can expect the syncing behavior described bellow.

Syncing is Both

On adding a comment, it's synced on all the linked issue/s.

On editing a comment:

  • if it is has been created by the system, it’s synced only on the source issue.
  • if it has been created by by the user, each issue having a comment synced with it is processed and the comment updated.

On deleting a comment:

  • if it is has been created by the system, the source comment is deleted and each issue having a comment synced with it is processed and the comment deleted
  • if it has been created by by the user, each issue having a comment synced with it is processed and the comment deleted.

On issue creation and linking via the Quick actions buttons all and only the comments added by the user on the source issue are synced on the created/linked issue.

On issue linking via the Quick actions buttons:

  • all and only the comments added by the user on the source issue are synced on the linked issue
  • all and only the comments added by the user on the linked issue are synced on the source issue.

Syncing is source versus target

On adding a comment on the source issue, it's synced on all the linked issue/s.

On editing a comment:

  • on the target issue it’s NOT synced on the source issue.
  • if it has been created on the source issue by the user, each issue having a comment synced with it is processed and the comment updated.

On deleting a comment:

  • on the target issue, the source comment is NOT deleted
  • if it has been created on the source issue by the user, each issue having a comment synced with it is processed and the comment deleted.

On issue creation and linking via the Quick actions buttons, all and only the comments added by the user on the source issue are synced on the created/linked issue.

On issue linking via the Quick actions buttons all and only the comments added by the user on the source issue are synced on the linked issue.

Syncing is target versus source

On adding a comment on the target issue, it's synced on all the source issue/s.

On editing a comment:

  • on the source issue it’s NOT synced on the target issue.
  • if it has been created on the target issue by the user, each linked issue having a comment synced with it is processed and the comment updated.

On deleting a comment:

  • on the source issue, the comment on the target issue is NOT deleted
  • if it has been created on the target issue by the user, each linked issue having a comment synced with it is processed and the comment deleted.

On issue linking via the Quick actions buttons, all and only the comments added by the user on the linked issue are synced on the source issue.

Summary, Description and Custom fields

Sync behavior for the fields Summary, Description, Custom fields, Assignee, Reporter is the same for Partnerships configured across the same or different source and destination Url/s.

Depending by the configured sync versus you can expect the syncing behavior described bellow.

Syncing is Both

On issue creation via the Quick actions buttons, data are synced from the created issues to the source and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.

On issue creation via the Escalate issue post function, data are synced from the source issue to the target when Sync on create is set to true, syncing is not active on issue creation if Sync on create is set to false.

On linking an existing issue, data are synced from the linked issues to the source and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.

Syncing is source versus target

On issue creation via the Quick actions buttons, data are synced from the source issue to the created issue.

On issue creation via the Escalate issue post function, data are synced from the source issue to the target when Sync on create is set to true, syncing is not active on issue creation if Sync on create is set to false.

On linking an existing issue, data are synced from the source issue to the created issue and, if other synchronizations have been configured on the linked issue, syncing is propagated again indefinitely.

Syncing is target versus source

On issue creation via the Quick actions buttons, data are synced from the created issue to the source issue.

On issue creation via the Escalate issue post function, data are not synced.

On linking an existing issue, data are synced from the linked issue to the source issue and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.

Component, Affect Version and Fix Version syncing behavior

Sync behavior for the fields Component, Affect Version, Fix Version is basically the same behavior described for Summary, Description and Custom fields.

In addition, cause of each of them can be associated to one, null or a list of values, you can expect the synchronization on adding and deleting a value from the list by following same behavior already described.

The major aspect differs those specific fields from the other type of synchronization is that sync can fail due to different Versions and Components settings across different projects and/or JIRA instance.

When sync fails due to the mentioned scenario, Comments are logged to alert the user for syncing failure. See HQL - General troubleshooting guidelines for further information on this topic.

Notice that when sync fails as default the add-on set to Null the value of the target field. An exception is made for field configured to be required where the existing value is retained.

Priority, Assignee and Reporter syncing behavior

Sync behavior for the fields Priority, Assignee and Reporter is basically the same behavior described for Component, Affect Version and Fix Version, including the behavior on sync failure but

as per Summary, Description and Custom fields behavior they can assume only one value.

Fields Assignee and Reporter cannot be configured on a field mapping to have Sync on Create = True and it implies the following limitations:

  • on issue creation and linking via the Quick actions buttons the issue create screen will not be populated by having the values of the source issue
  • on issue creation via the Escalate issue post function the issue  will not be populated by having the values of the source issue.

Issue History updates due to synchronization

Updates on issue’s data caused by a synchronization performed by Herzum Quick Linker are retained same way of updates applied by an user.

Notice that the applied updates are attributed to the user configured on the partnership as source/destination credential:

  • synchronizations applied on the source issue are retained as made by the user configured on partnership source credentials
  • synchronizations applied on the target issue are retained as made by the user configured on partnership destination credentials.
  • No labels