Work Flow Jira 4.4?

[vivek.aniyan]

Anybody having any example links for this ?

[Nic Brough -Adaptavist-]

Mmm, I thought there was a "particular user" condition, must be from one of the plugins in this Jira install, sorry.

As you say, it's still the worst way to do it - if the requirement changes (e.g. person moves on and is replaced, or someone else needs the authority), you don't want to be editing a workflow to enable it for them.

It would be far better to use the standard group or role condition (you could create a role specifically for it, or limit it to "project admin"), which is a lot easier to main tain.

>IMHO this is not quite consistent across workflow conditions and permission/notifications

I don't understand that statement. I've found it consistent and reliable throughout. Complex, yes, but that's the price for flexibility.

[JamieA]

Totally agree about not hard-coding user names, but have to agree about creating a new role. Roles are unfortunately global, and cause no end of confusion when they are not relevant. In most projects the new role would have no significance, yet people will add users to the role, and expect some sort of additional power, which they won't get. We have 10 roles, of which 7 do nothing in 99% of the projects... causes endless grief.

[Nic Brough -Adaptavist-]

I found the comment about performance odd too - I've not made heavy use of the script runner, but I've never seen any hint of speed problems with what little I have done!

[Dieter]

i read that somewhere, but really do not remember anymore where. And i also stepped in that trap before i read this. We had some really complex conditions which called 10 groovy scripts in the worst case and issue view performance got a nightmare. After we changed the conditions to just checking some flags which had been set in workflow post functions it worked 20 times faster.

I investigated that behaviour further and noticed that the workflow conditions are not just called once when an issue is displayed. I saw them called at least three times and this explains why conditions should be as fast as possible ... and of course calling groovy has a lot of overhead

[JamieA]

Yes, conditions are called 3 times, which is crazy, but it's the same for java or groovy. Rather than calling 10 scripts they should be consolidated to one script which should be faster. But yes in general, you are right, if there is anything you should be concerned about performance it's on Conditions. If you have 50 views in your issue navigator the condition script could be running 150 times.

"and of course calling groovy has a lot of overhead" this is true in the sense that creating millions of objects will be 100 times slower than in java, although it will still take only 1 second. In the context of Lucene, and jdbc etc, I don't think the overhead is generally significant, providing like is compared with like.

[Nic Brough -Adaptavist-]

Mmm, I thought there was a "particular user" condition, must be from one of the plugins in this Jira install, sorry.

As you say, it's still the worst way to do it - if the requirement changes (e.g. person moves on and is replaced, or someone else needs the authority), you don't want to be editing a workflow to enable it for them.

It would be far better to use the standard group or role condition (you could create a role specifically for it, or limit it to "project admin"), which is a lot easier to main tain.

>IMHO this is not quite consistent across workflow conditions and permission/notifications

I don't understand that statement. I've found it consistent and reliable throughout. Complex, yes, but that's the price for flexibility.

[Dieter]

not consistent because permissions/notifications allow persons,roles and groups on the other side workflow conditions just allow roles and groups

[vivek.aniyan]

Hi Everybody,

I have used the role assignement by creating a new role to the system. So that I can avoid the later edition of the workflow for the replacement of the user. But unfortunately I am not in a position to give an assignment to a particular user at the Post Function of a Transition since there is no such option even for assigning the operation to 'group' or 'role'. Any suggestions please ?

[Dieter]

If the transition should be restricted to user 'smith', use this expression in a groovy script runner condition: passesCondition = ((WorkflowContext) transientVars.get("context")).getCaller().equals("smith") Please check https://studio.plugins.atlassian.com/wiki/display/GRV/Conditions for the details which imports you need

[Nic Brough -Adaptavist-]

That's complete overkill - you don't need the script runner at all- just use a {"person X", "role Y" or "group Z" can perform this transition} condition. (Actually, I wouldn't use person, because it's more flexible to use role or group - you then don't need to edit the workflow if the person changes)

[Dieter]

Hi Nic,

i know that groovy scripts should be avoided in conditions for performance reasons but i understood the original question as if only a particular _logged in_ user should be able to execute the transition. I just couldn't find any standard condition checking exactly "person X".Also the popular plugins JSU and Misc Workflow don't have something like that.

Only checking the logged on user against "role Y" and "group Z" is possible with standard conditions. IMHO this is not quite consistent across workflow conditions and permission/notifications

I agree with you that it's better to never hard code a user name in the workflow but it was asked ...

Regards,

Dieter

[JamieA]

Is it overkill but then it's easy to extend with more complicated conditions if and when you need it. But even with the script runner, it would be better to use the Simple Scripted Condition and just say *currrentUser.name == "smith"*. I'm not convinced of the performance overhead either, not with recent versions anyway... the class is cached. Compared to a jdbc call the overhead of groovy's plumbing is negligible.

[vivek.aniyan]

Hi All,

I am creating a workflow which has four steps

<Start>

create <Open>

Documentation Completed <Documented>Any Cahnge<Open>

Close Change <Closed>

I wanted to do the transistion of <Documented> to <Closed> only by a particular User.

How Can I give the post condition or pre condition restricted to a particular User?

[Nic Brough -Adaptavist-]

Er, could you explain the question? The default Jira workflow is in the documentation, along with lots of stuff around editing it. A search in there (or google of course) will get you there...