Are there any other plugins that can work with OpenSymphony? I saw these two given by Danial.
They do not provide what we need. Has anyone got a substitute for Open Symphony with custom plugin?
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)
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.
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
I'm not sure which plugin is making the call, but it has the class call of:
To resolve this you should try:
Atlassian Support - San Francisco
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.
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.
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!
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.
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.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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