[#JRA-14164] Jelly TransitionWorkflow tag in forEach loop sets wrong assignees

JIRA

Jelly TransitionWorkflow tag in forEach loop sets wrong assignees

Created: 18/Dec/07 07:11 PM Updated: 02/Jan/08 04:15 PM

Component/s:

Jelly

Affects Version/s:

3.7.1, 3.7.2, 3.7.3, 3.7.4, 3.8, 3.8.1, 3.9, 3.9.1, 3.9.2, 3.9.3, 3.10, 3.10.1, 3.10.2, 3.11, 3.12

Fix Version/s:

3.12.2

Time Tracking:

Not Specified

File Attachments:

None

Image Attachments:

1. changegroup.png
(12 kB)

Environment:

https://support.atlassian.com

Issue Links:

Reference

This issue relates to:

~~JRA-11768~~ Jelly TransitionWorkflow tag forces issue to be reassigned

Participants:	Anton Mazkovoi [Atlassian], Ian Daniel [Atlassian], Jeff Turner [Atlassian] and Michael Tokar [Atlassian]
Since last comment:	36 weeks, 1 day ago
Resolution Date:	02/Jan/08 04:15 PM
Labels:

Description

« Hide

If we have a Jelly script, running a filter that results >1 issue, and transitioning them, eg:

<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib" xmlns:core="jelly:core" xmlns:log="jelly:log">
        <jira:RunSearchRequest filterid="10020" var="issues" />
        <core:forEach var="issue" items="${issues}">
            <log:warn>Transitioning issue ${issue.key}</log:warn>
            <jira:TransitionWorkflow key="${issue.key}" workflowAction="Resolve Issue"/>
        </core:forEach>
</JiraJelly>

Then all transitioned issues will have their assignee set to that of the first encountered issue.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Jeff Turner [Atlassian] added a comment - 18/Dec/07 07:14 PM

SQL to identify changegroups with this problem:

atl-support-jira=> select changegroup.*, ci1.newstring, ci2.newstring from changegroup, changeitem ci1, changeitem ci2
   where changegroup.id=ci1.groupid and changegroup.id=ci2.groupid and ci2.id=ci1.id+1 and
   changegroup.author='atlassiansupport' and ci1.newstring='Inactive - Pending Closure' limit 1000;
   id   | issueid |      author      |          created           |         newstring          |        newstring        
--------+---------+------------------+----------------------------+----------------------------+-------------------------
 568612 |   53447 | atlassiansupport | 2007-12-18 16:39:55.766-06 | Inactive - Pending Closure | Kay Nny Lee [Atlassian]
 568622 |   53312 | atlassiansupport | 2007-12-18 17:02:13.207-06 | Inactive - Pending Closure | Nick Pellow
 568623 |   53337 | atlassiansupport | 2007-12-18 17:02:33.026-06 | Inactive - Pending Closure | Nick Pellow
 568624 |   53059 | atlassiansupport | 2007-12-18 17:02:39.14-06  | Inactive - Pending Closure | Nick Pellow
(4 rows)

[ Permlink | « Hide ]

Ian Daniel [Atlassian] added a comment - 18/Dec/07 07:31 PM

Jeff's database query against the change tables shows that last night was the only time that this has occurred on SAC.

[ Permlink | « Hide ]

Jeff Turner [Atlassian] added a comment - 18/Dec/07 11:17 PM

This is fairly easy to replicate:

Create a filter returning 2 or more issues.
Set the first (by filter order) issue's assignee to someone
Run the described Jelly script in the Jelly runner page, substituting your filter's ID in.

I believe this bug was introduced in 3.7.1 when we fixed ~~JRA-11768~~. Prior to 3.7.1, the transitionWorkflow tag required an assignee to be set explicitly.

[ Permlink | « Hide ]

Ian Daniel [Atlassian] added a comment - 19/Dec/07 04:28 PM

It is good that this is readily reproducible. I'm just curious as to why we haven't seen it in SAC prior to yesterday if it has been an issue since 3.7.1. Any theories?

[ Permlink | « Hide ]

Anton Mazkovoi [Atlassian] added a comment - 19/Dec/07 10:10 PM

I am with Ian here. Why did the bug only surface now?

[ Permlink | « Hide ]

Jeff Turner [Atlassian] added a comment - 19/Dec/07 10:44 PM

> I am with Ian here. Why did the bug only surface now?

I have no idea. The bug is clearly present in older versions.