| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
This is the documentation for JSU for Jira Server/Data Center. If you are using JSU on Jira Cloud, see our JSU Cloud documentation. |
On this page:
|
| Info |
|---|
The 'Copy / Move Attachments' feature is available from JSU 2.9.0 |
Description
This The ‘Copy or Move Attachments’ post function will copy copies attachments from/to all related issues. A user defines You can define which issue should be a source and which is a destination. Any Any number of attachments can be copied to the related issue/-(s).
Configuration
...
Position of the Post Function
If you use 'Move Attachment' (see bellow) you must position the post function before 'Update change history for an issue and store the issue in the database.'
You can add this post function several times in one transition and it will duplicate attachments.
...
The view screen of a transition displays all parameters in a readable form:
COPY ATTACHMENT FROM/TO ALL ISSUES RELATED AS
...
...
Precondition
If you are using preconditions with a JSU post function, you can use the following options to define how the precondition is evaluated:
Ignore precondition (default): Every precondition is ignored which means that the post function will always be performed
True: Precondition must be true to execute a post function
False: Precondition must be false to execute a post function
Issue relation
You have several options which define which issue/s will be treated as a source/ or destination for attachments.
Several of JSU's workflow modules provide the option the define the scope of the module on some related issues.
For example instead of copying attachments from one issue to the others you might choose to copy them from all linked issues to the issue in transition (e.g. to group all attachments within one issues)
TYPES OF ISSUE RELATIONS
Related issue will be found Related issues are evaluated by one of the following JIRA following Jira concepts:
Issue Link
: You can
defineselect the link type to
defineddefine which issues
exactlywill be affected by the
operation.
Since JSU 2.2.0, we introduced the value ANY. The operation willpost function action. Select
ANYif you want the action to be performed on any linked issues.Parent /
Sub-TaskSubtask:The related issue is either parent or
sub-tasksubtask of each other.
Epic / Issue in Epic
This :This is only applicable
,if you
have JIRAhave Jira Software installed.
The other issue is either the epic related by an epic link, or it is part of an epic.
JQL: A JQL query will be executed to retrieve the issues. You can use placeholders in the JQL query which will be replaced with the current field values of the issue in transition.
...
For tips on writing the JQL query, see JQL Reference.
Issue in transition
We use the term 'Issue in Transition' when we refer to the issue for which a workflow condition is checked, for which a workflow validator is examined, or for which a workflow post function is performed.
Or in other words that , the issue , which triggered a workflow condition/validator/post function to be executed.
| Warning |
|---|
| Note |
Conditional copying attachments Conditional copying attachment (controlled by custom field) is always checked always only for the issue in transition. Independently if , regardless of whether the issue in transition is a source or destination. |
...
Source and destination
You can define the issue in transition as the source or destination of the copy operations, while you define the other end with an issue relation.
The field value will then be read from the source issue and be written to the destination issue. Other workflow modules do not have source and destination. So ; you just define the issue relation, which will apply for to that workflow module. For example Create a Linked Issue will just create a new issue and then connect it with some Issue Relation to the issue in transition.
Controlled by Custom Field
...
Perform As User
With Perform As User, you can specify a different user account that owns the necessary permissions. Usually, this user account is assumed to be only technical (impersonation), with broad permissions, but not used to log in to a Jira account as a person.
If you don't specify a user here, the transition on the related issue is performed as the same user who triggered this post function on the origin issue by default. Therefore that user must have the necessary permissions on the related issue. In some restrictive setups, that user might not have the permissions on the related issue or even might not have access to the project of the related issue.
In combination with the User is in Any Users condition, you can hide a transition from all users other than the 'Perform As User' user.
Controlled by custom field
With a checkbox custom field on the transition screen, so the user users can control some of the copy functionality.
...
For example, a checkbox 'Copy Existing Attachments' might be checkbox is configured as Custom Field a custom field that enables copying existing attachments. Only if If it is tickedselected, all attachments will be copied.
Typically this checkbox custom fields field won't appear in on the normal issue screen of the issue. Instead of letting the allowing a user to choose to copy/move the attachments, you can also configure it to either never /or always copy them.
Tip: You might choose '
Move option
If you choose the Move option for 'Copy/Move Attachments added during Transition'. The , when a user then adds some attachments on the transition screen of the source issue. However since they are moved to all related issues, it feels appears as if he just they added the attachments to all related issues.
...
Position of the post function
Jira transitions include essential post functions that are executed in a specific order. When adding JSU post functions to a transition it is important to position the post function with respect to the essential post functions.
If you use ‘Move Attachment' you must position it before 'Update change history for an issue and store the issue in the database.’
| Note | ||||||
|---|---|---|---|---|---|---|
If you use Move Attachments added during Transition ' it is important that the 'Copy / Move Attachments' Post-Function post function is before JIRA Post-Function Jira’s 'Update change history for an issue and store the issue in the database' !
Exception from this rule is a situation when Transition issue is a destination issue. In such case "Copy Move Attachments" has to be placed between "Update post function. In such cases the ‘Copy Move Attachments’ must be placed between ‘Update change history for an issue and store the issue in the database" database’ and "'Re-index an issue to keep indexes in sync with the database"database’. |
| Warning |
|---|
Due to a Bug in Jira JRASERVER-65939, 'Copy or Move Attachments' functionality, which are added through a Transition Screen, does not work in Jira 7.5.x & 7.6.0. If you require this functionality, please upgrade to minimum Jira Version 7.6.1! |
...
Tip: You might setup a special transition screen to mainly copy those attachments to all linked issues. So it feels more like it would be the create screen of the new issue. In that case, you won't show those fields on the origin issue, but reset them again afterwards (just empty or back to the default value).
...
Existing attachments are not copied again
When an identical attachment (same file name and same content) already exists in the destination issue, it will not be copied again. This is the case for both, existing and transition attachments.