Open Symphony

[KP11]

Are there any other plugins that can work with OpenSymphony? I saw these two given by Danial.

https://marketplace.atlassian.com/plugins/com.innovalog.jmwe.jira-misc-workflow-extensions

https://marketplace.atlassian.com/plugins/com.googlecode.jira-suite-utilities

They do not provide what we need. Has anyone got a substitute for Open Symphony with custom plugin?

[Nic Brough -Adaptavist- · Accepted solution]

There is no "open symphony plugin", so I don't understand the question. There's nothing to substitute.

The two plugins you've got there are very useful for adding functionality to workflows if that's what you need, but if you pull opensymphony out of Jira, you won't have ANY workflow at all (or a working Jira)

[KP11]

Yes we were on a old version 2 years back that it worked. OpenSymphony is not supported

was what we were told. I did no see the same functionality with the two plugins

[Nic Brough -Adaptavist-]

Again, there is no Opensymphony plugin, even for v2 of Jira, so I don't know what you are talking about.

What functionality do you think this plugin provided?

[Nic Brough -Adaptavist-]

Right, so it's not an Opensymphony plugin, it's a plugin CALLING Opensymphony.

Is the plugin a publically available one? If so, then, as David says, you need to get a new version from the vendor. If they no longer provide/support it, then you'll need to find or write an alternative.

If it's your own plugin, then you need to adapt it to replace what Opensymphony was providing. At a guess, it's the user functionality (because that's one thing OS did and it's all changed), so you need to rewrite your code with v5 user code (look for crowd.embedded), recompile and retest.

Again, what functions did your plugin provide? If we know that, we might actually be able to help you.

[KP11]

Our plugin was calling Open Symphony. We assumed that was the issue from the Jira record JSP-151595.

Our plugins stopped working on 5.2

• The plugin is calling open symphony, which is no longer used by JIRA in the latest versions.

I'm not sure which plugin is making the call, but it has the class call of:

• com.ibaset.jira

To resolve this you should try:

• Upgrading this plugin
• Removing the workflow function being called

Regards,

David Chan
Atlassian Support - San Francisco

[KP11]

Vendor/Contractor custom plugin

It provided the following:

1. Only allow one USER TYPE to set Jira Record to Review even if they are not assigned to the Jira record? example: Only Workflow Administrator can change to Review and not Developer.

2. Trigger to 2 fields to change when one field is changed? Auto trigger. Example: If Assignee field is changed then also change another field with the same?

3. When a record is reopened it gets assigned to the person who reopened it. We need it assigned to the person it was assigned to when it was closed.

[Nic Brough -Adaptavist-]

Ok, so are they not willing to upgrade it for you? Do you have the source code and the will to do it yourself?

On the individual functions

1. I don't understand that really. Is "record to review" a status? If so, then you don't need any code to do that - you just add "conditions" to your workflow. Like "only people in the role of workflow-admin can use this transition that goes to RtR". Or have I misunderstood?

2. Is this on-screen, or behind the scenes? Using your example, if the user changes assignee when they are in the create or edit screen, then you expect another field's options to change? Or, after a user commits a change, Jira quietly updates the field for them without interaction?

3. That sounds like you have a post-function that sets the assignee to "current user". That's fine, you can just remove it from the transitions. But the second requirement "assign to person who was assignee when it was closed" must be in the plugin you had.

I can see that the two recommended plugins can't quite get there (although one of them does provide "assign to current user"). If you can't recompile your plugin, then I'd look at Jamie Echlin's script runner - that can definitely do the behind-the-scenes updates in points 2 and 3, and provide a lot of other flexibility too. If point 2 is a front-end thing, then you'll need javascript (but I'd also look at the behaviours plugin, which can do that as well)

[KP11]

1. No it can be any status. We only want one Type of Role to change status. Restrict to Type Developer role.

2. Behind the scenes. Or, after a user commits a change, Jira quietly updates the field for them without interaction? Thats how the plugin worked

3. Yes we looked at post functions and it was only Project Lead or Developer Lead

Vendor/Contractor is no longer available. We don't want custom code because of upgrade issues. Trying to use Jira out of box!

[Nic Brough -Adaptavist-]

Oh, that's a shame about the vendor, that they cannot help. I understand the desire to get rid of custom code - that's why I try to avoid it where possible as well. At the very least, I make sure I (and my clients, of course) have copies of the core code for a plugin so that we can do upgrade work if necessary.

Anyway

I'm afraid you can't do points 2 or 3 without some code that is not "out of the box". I mentioned the script-runner earlier - while it is customised code, it's not actually specific. It enables you to add a minimal amount of code (in one or many places) to do things that you would normally need to write your own plugin to provide.

On to your specifics.

1. Add a condition to ALL of the transitions, saying "only people in developer role". That's out-of-the-box in Jira already

2. That's a job for a (remarkably simple) script runner script. Or a small plugin

3. As point 2 - a little more complex as you need to read back through the history, but still not hugely painful.