Using JIRA Suite Utilities (JSU) plugin, I am able to add a post-action to a workflow transition to set the value of a custom field. When I do this, it appears that the PCP export dumps out a field.name such as "customfield_10009" rather than what I had entered, "Job Number".
It looks like JSU uses a post action class name like "com.googlecode.jsu.workflow.function.UpdateIssueCustomFieldPostFunction", which gets into the export properly, but on the import it looks like it doesn't get hooked up. When I attempt to view the workflow transition's post actions, I get an error in my log (which I can provide if needed), and instead of something like this in the UI;
Set the Job Number field to 9SND
I get this;
field.value = 9SND
field.name = customfield_10009
A couple questions arise:
First, do you plan to support other JIRA standard plugins (like JSU)? The PCP looks very useful, but this will break it for me if not.
Second, there are other id's embedded within the export file for my custom workflow definition (custom steps and actions, for example, which do not depend on other Plugins). I suspect as I go further in testing that I will find a problem in getting these to link back up on import. This is just a heads up as to where I need to continue my testing, but none of that matters unless the first question is resolved.
The problem with this configuration lies in the JSU plugin workflow extensions not being supported by Project Configurator plugin (PCP) at its current version. It supports conditions, post-functions and validators defined in standard JIRA. Being this way, PCP does not "realize" that JSU post action "update custom field" has a field argument that must be translated properly before loading it into another instance of JIRA.
With respect to your questions:
1) I will evaluate if it is possible to add support for JSU in PCP and post it, together with an estimated release date, in the next days.
2) The other id's embedded in the XML file are IDs for steps and actions. These are used internally as a reference within the workflow descriptor and are OK. They need not be changed.
I am glad you managed to find a workaround!
Could you send me the workflow XML file as you can download it from JIRA, and the exported XML file with the project configuration that PCP dumps?
If it is more convenient, send it to firstname.lastname@example.org.
Thanks for your interest in PC
Sent exports to support.
I was able to work around my immediate issue by importing two times. First time, I get all the custom fields, issue types, etc. In addition, I get a workflow with some bad pointers to some non-existent custom field IDs. I look up the correct (new) IDs for the custom fields I need in my workflow, and hand edit the xml with those. Then I delete the workflow, and workflow scheme, and import a second time. After that, the custom fields called out in the workflow are hooked up correctly.
I'll move on to testing my other concern of step IDs and transition IDs in the xml. These could have a similar issue with other custom steps/transitions having been installed via some other mechanism causing an ID conflict.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
This September 6-7, hundreds of Atlassian App developers will flock to Barcelona Spain to build skills, discover product roadmaps, meet face-to-face with the Atlassian team, and learn how to extend t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG