Hi All,
I would like this automation to overwrite the FixVersion field on an issue based on a cloned issue's FixVersion, but for some reason, if the destination issue already has a FixVersion it doesn't overwrite it. What am I missing here?
Then: Edit issue...
Hi @Áron ,
would you please share us screenshot with the configuration of Edit issue fields action detail?
Thank you!
Thank you. Actually it looks good, I believe this should work. I will test it using my instance and let you know. Maybe we will need to use additional fields...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you! It actually runs with "Success" but for some reason if I change a FixVersion on the trigger issue and run the rule again it doesn't overwrite it on the destination issue. :S
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Áron
Would you please post an image of the audit log from a rule execution that should have worked? That may provide some insights. Thanks!
Best regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I've just tested it with manual trigger and it works for me.
Hopefully image of the audit log would help us determine, what's going on.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Bill Sheboy
What seems odd is that the rule couldn't find related issues (every WPEMEA ticket gets cloned to open a PM ticket - hence all of them has relations (clones / cloned by))
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ah... I see some things of note:
Please note the scheduled issues returned (in the PM project) and the branch on linked issues returned (in at least the WPEMEA project). Is this a project-level or a global/multi-project rule? If it is project level this will only process items within the scope of the project where it runs. What is your intent of issues to update: project or instance scope?
And...if this is multi-project, the versions are specific to a project. So you would need to confirm their existence in the target project in order to assign the values (duplicate version names but different instances by project). I wonder why that doesn't show as an error in rule execution...
And...note how the schedule returns more than 100 issues? I believe rule execution is limited to 100 issues from a JQL, branch, LookupIssues, etc. If you expect more than 100 issues you may need more criteria to limit the result set (with JQL)...which could require multiple similar rules.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.