Skip to end of metadata
Go to start of metadata

Getting Help

Please visit our Support Page for more information.


This plugin provides a set of workflow extensions (conditionsvalidators and post-functions) that you can use to customize your JIRA workflows.

  • No labels

94 Comments

  1. We have following scenario. Some of our bugs/task are created by QAs. For that issues we need Resolve them to Reporters. For all other issues we need assign them to QA Lead.

    Is it possible to write simple unification of "Assign to last role member" and "Assign to role member". I mean post function that will works as "Assign to last role member". In case noone in specified group had worked with issue than fallback to "Assign to role member".

    Den

    1. Den,

      have you tried to put an instance of "Assign to role member" (to QA Lead) followed by an instance of "Assign to last role member"? I believe that if "Assign to last role member" does not find anyone in the specified role member in the issue's history, it will simply not change the assignee (therefore leaving the assignee specified by "Assign to role member").

      David.

      1. But how can I prevent "Assign to role member" assignment in the case "Assign to last role member" has found someone in the history?

        Den

        1. If you put "Assign to role member" before (above) "Assign to last role member", then the latter will override any change the former will have made (if the latter actually finds a matching user). This is because post-functions are executed in sequence.

          Let me know if this works.

          David.

          1. David, yes, it works!

            Stupid me! Could solve this puzzle by reordering postfuncitons myself.

            Thanks again,
            Den Orlov

  2. Unknown User (kherrmann)

    I'm trying to use the "separation of duties" condition to prevent the reporter from seeing certain workflow actions, is that possible?  When looking at a ticket that is a just opened state, I don't see anything when looking at the transitions for the issue, so it seems like the "separation of duties" action would not work in these cases, as it doesn't consider the create a transition.  Any ideas how we can do this?

  3. Unknown User (kherrmann)

    I'm trying to use the "separation of duties" condition to prevent the reporter from seeing certain workflow actions, is that possible?  When looking at a ticket that is in a just opened state, I don't see anything when looking at thetransitions for the issue, so it seems like the "separation of duties" action would not work in these cases, as it doesn't consider the createa transition.  Any ideas how we can do this?

    1. Kyle,

      unfortunately, I don't believe you can use the "separation of duties" condition for that purpose. And I've never seen a "Not Reporter Condition" (the reverse of the "Only Reporter Condition" that is shipped with Jira).

      You can try using http://code.google.com/p/jira-plugin-pack/, more specifically the User in/not in specified field workflow condition (using the "Reporter" field).

      David.

  4. I've add PRJxTesters : default property to one of our test leads and removed from other. But it looks like "Assign to role member" post function doesn't detect that modification and still assign issues to old test lead.

    Should I restart jira after user property changes?

    Den

    1. Den,

      no, you don't need to restart Jira.

      Please post a Jira, describing in more details your transition.

      David

      1. After JIRA restart all works correctly.

        Den

  5. We moved to jira 4.0.1 and JIRA Misc Workflow Extensions 1.5 from jira 3.1.13.

    And now experiencing problems with "Assign the issue to the last user from the Testers role" post-function. I move issue by transition that should invoke the post function. Issue that was reported by user from Testers role. In logs I see:

    2010-02-02 18:18:37,750 http-8080-Processor47 WARN dorlov 65917x37244x2 1uby1rc http://jira.iiko.ru:8080/secure/CommentAssignIssue.jspa jmwe.plugins.functions.AssignToLastRoleMemberFunction AssignToRoleMember is configured to assign to the last user in project role Testers . There are was no such user found in the change history. (no assignment will be made)

    What should I re-check? Is this a bug?

    Den

    1. Den,

      this is a limitation of the "Assign to last role member" function. It will not consider the submitter when looking for previous assignees of the ticket - simply because the submitter was never assigned to the issue.

      David.

      1. Is it possible to enhance "Assign to last role member" functionality? We use this post function to realize our "assignee to QA if issue was opened by QA or assign to QA Lead if it was opened by non QA person" rule. Without considering submitter "Assign to last role member" post function become useless for us.

        Den

        1. Please post a JIRA, I'll look into it when I find some time (hopefully soon).

          David.

  6. Request a post condition that sets one field to another (like-type) field value, ie. Due Date to custom field "Start Date".

    1. You should use the "Jira Suite Utilities" plugin, which includes such a post function.

      David.

  7. Unknown User (ktempesta)

    Any chance of getting a "Copy Field Value to Sub-task" post function? What we really need is a way for newly created sub-tasks to inherit custom field values from the parent when they are created. A function to update specific fields in sub-tasks when the parent issue is edited would be great too. Would that be within the scope of this plugin?

    1. Hi Kathy,

      Take a look at Minyaa (http:\\www.minyaa.com) that provides Inherit (On sub-task edition) and Propagate (on Parent Issue edition) Workflow Post-funcyion.

      Vincent

    2. If you're not willing to purchase Minyaa, you can post a feature request in JIRA: https://studio.plugins.atlassian.com/secure/CreateIssue.jspa?pid=10793&issuetype=4

      I cannot guarantee I'll be able to implement it quickly though.

      David.

  8. Unknown User (tim.davies)

    The section*"Using Post-functions in the Create transition"* that states "If you insert a Post-function in the Create transition, you must make sure that you move it down to after the Creates the issue originally built-in function." seems to be misleading if you're using the "Set Issue Security From User's Project Role Function". On my installation of JIRA (version 4.1), I had to move the Post-function transition before the Creates the issue originally built-in function for it to correctly set the security level of the issue.

    Fixed this by looking on your bug section (specifically JMWE-33)

    1. You're right, I've updated the documentation accordingly. Sorry about that.

    2. Unknown User (korotkov)

      Same for the "Set Field Value From Parent Function": the post function must stay before the "Creates the issue originally".

      (JMWE 2.4.1, JIRA 4.3.2)

      1. Hello!

        This does not work for me in Jira 4.2.2 with JMWE 2.4.1?

        Even when the "Set Field Value from Parent" post operation is placed before the "Create the issue originally" the values from parent issues are NOT filled to field-boxes.

        Any other tip to get this working? (Konstantin: Seems you got this running on your 4.3.2 configuration?)

        Thanks & Regards,

         Markus

        1. What do you mean by "the values from parent issues are NOT filled to field-boxes"?

          To make sure there is no misunderstanding: post-functions run after the transition screen, so they cannot impact what gets displayed during the transition.

          1. Hello David,

            from comments above I got a wrong impression. Right, Post-actions are done after transitions.

            I'm looking for a kind of Pre-Condistions-List where I could copy data from parent to the yet-not-created-child-task.

            Lot of my users request to have some data copied from the parent to avoid adding data twice. (I've already implemented the post operations but people could not remember to keep some fields empty and let the automatically fill after "create"-action...they want to see the copied content earlier...)

            Regards, Markus

            1. Well, there are two solutions:

              1. You get Atlassian to implement the notion of "pre-functions" (to mirror post-functions) that would be run before the transition screen shows up (good luck!)
              2. You use the Behaviours plugin, which is not for the faint of heart but can be used to achieve the desired effect.

              Let us know if you're successful with any of these approaches.

              David.

              1. Hello David,

                I'll skip option 1) (seeing little to no probability to get this implemented in next x years) and try the Behaviours plugin. ;)

                Regards, Markus

        2. What do you mean by "the values from parent issues are NOT filled to field-boxes"?

          To make sure there is no misunderstanding: post-functions run after the transition screen, so they cannot impact what gets displayed during the transition.

  9. Unknown User (raxdaman)

    Feature request for conditions to verify that two or more statuses are passed to go to the next status which requires those two or more previous statuses.

    Example. I have a task in status x. From x you can got to status y and z. From z you can go to y and vice a versa (all that possible with standard JIRA). Now after y and z comes status w, which requires both y AND z to be passed. So, possible scenarios would be:

    1. x -> y -> z -> w

    2. x -> z -> y -> w

    Can't figure out how to do it in JIRA.

    1. Normally, feature requests should go into JIRA. However, in your case, it's ok because the feature actually already exists.

      You can use the Previous Status Condition included in JIRA Misc Workflow Extensions. On the "z">"w" transition, you add a condition on the "y" status, and on the "y">"w" transition a condition on the "z" status. Or if you want to create a common transition for both, you can include the two aforementioned conditions combined with the "OR" operator.

      David.

      1. Unknown User (raxdaman)

        Thank you very much for the instructions, David!

        Rainer.

  10. Hello all,

    I need to solve following scenario. Maybe this could already be done with your great plugin, might be an improvement idea or any other way is already there:

    Situation: Parent-issue -> Child-issue

    On some workflow transitions of the child-isse (e.g. open, send4approval,...) I need to copy some fields from the parent-issue to custom fields in the child issue:

    e.g. Copy the parent-Summary content to a custom field Parent_Summary

    or Parent-DueDate shall be copied to Child-Duedate or a custome datefield Parent_DueDate

    Any idea? TNX a lot!!

    BR, Markus

    1. Hi Markus,

      Unfortunately, my plugin includes the opposite function but not what you're looking for. It is indeed an idea for a new feature. Can you create a feature request in Jira?

      Note however that I'm not sure I'll be able to implement it in the near future - I haven't had much time to work on my plugin for the last 2 months...

      David.

  11. Unknown User (pat@mepatrick.com)

    Hi, I am trying to use "increase value of a field" to increase the priority of an issue when it is re-opened.  However, it doesn't seem to work.  Do you have some suggestions?

    Thanks!

    -pat

    1. Unfortunately, the priority field is not an integer field, so it won't work.

      You could use the Jira Scripting plugin, which allows you to write custom post functions in any scripting language - it's actually quite simple.

  12. Unknown User (david.mcintyre@stanford.edu)

    Can one of these Post functions set a date field to the current time/date stamp? I'd like to create a searchable field that can be filtered on when a ticket goes through a particular workflow step.

    1. Unfortunately not. There is a plugin that is supposed to do this, Jira Transition Search, but it hasn't been updated in a very long time and there have been some reports of it's incompatibility with recent Jira versions.
      You can create a feature request in our Jira project, but I can't guarantee when I'll be able to implement it.

      1. Unknown User (david.mcintyre@stanford.edu)

        Thanks for your response. We're going to try this with a database trigger to update the date field when the transition happens. If we can't manage that, we'll try the Jython plugin.

        1. I would advise against modifying the database directly because such changes will not be indexed and therefore will not be searchable.
          But using the Jira scripting plugin is easy, you should have no problem implementing what you need.

  13. Unknown User (rob.oaks@unirisx.com)

    Hi David:

    Regarding the "assign to last role member" post-function, is there a way to have it not exclude the current assignee?

    Thanks so much.

    1. Hi Rob,

      there currently isn't. You can create a feature request, but I can't say when I'll be able to implement it.

      Sorry,

      David

      1. Unknown User (rob.oaks@unirisx.com)

        It occurs to me that I can achieve the same effect by:

        • Running the "assign to role member" post-function to assign to a dummy role (e.g. Dummy) and then
        • Running the "assign to last role member" post-function to assign to the actual role, a member of which the issue was already assigned to when the transition occurred.

        Any reason this wouldn't work?

        Thanks so much David.

        1. Actually, I don't think it'll work, because the function looks at the issue history, which won't have been updated yet (it's updated at the end of the transition).
          David

  14. Unknown User (rob.oaks@unirisx.com)

    David: If you can explain to me why the technique above is not working I would be eternally grateful.

    Here's the sequence:

    • I created a project role called Type--System, that has one member, roaks.
    • An issue is assigned to user dclover who is in the Participant--Client & Non-Client role. Note that roaks is in the Participant--Client & Non-Client role as well.
    • Cancel Request transition is executed with the following post function sequence:
      • Assign the issue to the default user from the Type--Services role
      • Assign the issue to the last user from the Participant--Client & Non-Client role that had this issue assigned before.

    It should end up leaving the assignee as dclover but, instead, it assigns to roaks. It's as if it's never executing the 2nd post function above, or else the "assign to last role member" post function is not ignoring the current assignee, roaks, and just reassigning to roaks.

    This is an absolutely critical issue for me.

    Thanks David!

    1. If I understand correctly, it's for the same reason you stated yourself: because the assign to last role member function does not take into account the current assignee - and by current assignee, I mean the user the issue was assigned to before the transaction was triggered. Whatever change you make to the assignee during the transition, be it in the transition screen or using a post-function, is not considered as a change of assignee until after the transaction is finished.
      So I guess you'd need the improvement I suggested above to make your workflow work.

      1. Unknown User (rob.oaks@unirisx.com)

        David:

        Yes. It is exactly as you say.

        First let me say that the "Assign to last role member" (ALRM) post-function is, for us, one of the two most useful post-functions ever written — the other one being the "Back to previous step" post function that is part of the Minyaa suite. These post functions enable rich and complex workflows we absolutely require to create the rich JIRA functionality that runs oru operation. Thank you so much for creating it.

        This recent exercise has helped me to understand, however, that the inability to consider the current assignee actually precludes an entire class of workflow scenarios that are critical for us. In particular, it precludes scenarios that I would describe as follows:

        1. One or more steps are executed in a primary workflow.
        2. At any step along the primary workflow, a transition is executed that temporarily diverts to a secondary workflow and then returns to the primary workflow.

          An example would be a support or development workflow where, at any time, a project participant can execute a Request Info from role transition (where role could be any project role such as Developer, Tier 2 Support, etc.) that leads to an Awaiting Information from role step and returns to the primary workflow when a Provide Info to role transition is executed.

        By excluding the current assignee, ALRM can not reliably support any such scenarios because, for both transitions (to and from the secondary workflow), ALRM depends on the current assignee not being in the role to which you wish to assign the issue — a circumstance that, alas, frequently exists when the secondary workflow can be executed at many points along a primary workflow.

        It's tantalizing, because ALRM is a brilliant post function that almost get us there.

        I will certainly create a feature request, but I'm wondering if you would be open a short, paid engagement to resolve this issue. I hope I'm not being presumptuous in asking.

        Unfortunately, it's something that I need to resolve right away, as I've fallen behind on a critical deadline. If an engagement is not possible, there is an excellent JIRA developer I have worked with a couple times who could probably resolve this issue and then we could give you the code we used to resolve it.

        Please let me know your thoughts.

        Thanks again,
        Rob Oaks
        CTO
        Unirisx

        1. Rob,

          for the "Provide info" transition, I wouldn't use the ALRM function. I personally use a hidden "Return to user" field to which I copy the Assignee during the "Request Info" transition, and that I copy to the Assignee field during the "Provide Info" transition. This is way more reliable, and having the "requester" field can actually prove useful in some situations. Also, instead of using the "Back to previous step" function, I prefer to use conditional results, but this requires changing the workflow's XML definition. The advantage is that you can define a single transition that can return to a number of different statuses, depending on the original status before Request Info.

          For the "Request info from Role" transition, it still sounds strange that the new assignee (the person from whom the info is requested) would be the same as the previous assignee. It's like asking yourself the question...

          Anyway, if you really need the improvement to ALRM quickly, let's take this offline (I'm emailing you my contact info).

          David.

  15. Hello,

    We have version 1.5.3 of the plugin, and we're using "Assign to role member" with the following syntax:

    Property Key: defaultAssignee{n}  (where n is a number from 1 up, for example: defaultAssignee1)
    Property value: {ProjectName}x{RoleName} (for example: CoolProjectxQAMembers)

    I am just wondering if the plugin can cope with spaces. For example is it ok to use the following property keys/values for a user?

    Property Key: defaultAssignee1
    Property value: Development ProjectxProject Administrators

    Property Key: defaultAssignee2
    Property value: Third Level Helpdesk SupportxProject Administrators

    What happens if the property value contains multiple "x"s? How can the plugin distinguish project name part from project role part?

    Also what happens if the same property key has been used on multiple users? How does the plugin handle this case?
    For example imagine that user1 has a "defaultAssignee1" property key with value "Development ProjectxProject Administrators" and another user2 has a "defaultAssignee3" property key with the same value (i.e. "Development ProjectxProject Administrators").

    Thank you,
    Ioannis

    1. Well, this syntax has its flaws. That's why it's been replaced in later versions of the plugin.

      As for the case where two users are both declared as the default assignee for the same role, the post function will choose the first one it finds (in the order Jira lists them in its API - I have no idea what it is).

      David.

  16. Unknown User (liz_lovett)

    Using the Transition Parent Issue post function is there a way to check if the parent issue has any subtasks that are still open? Our parent issues tend to have 4 or 5 subtasks and I was hoping to have the Parent issue transition when all 4 or 5 subtasks are closed and not before.

    I tried using the condition on the parent issue that would not transition until all subtasks were closed but then the transition didn't happen at all. Any suggestions?

    1. I'm not sure it'll work, but did you try moving the post-function as far down the list as you can?

      David

      1. Unknown User (liz_lovett)

        Oh thanks! I'm really new to JIRA, but that did the trick.

        Thank you so much for your plugin.

  17. Unknown User (smartin)

    I'm trying to use the Copy Value From Field To Field post-function, but seem to be running into a problem. If I attach it to any other transition it works perfectly, but when I attach it to the Create transition, nothing happens. I've tried placing it at various different points among the post-functions, but don't seem to be getting anywhere. Am I doing something wrong?

    Thanks,

    Steve.

    1. Unknown User (speimann@curtisswright.com)

      Steve,

      The problem is that you have no existing field values to copy; the starting field values are all null.

      If you want to copy a just entered value, then you have to look it up in the change list.

      Luck!
      Scott

      1. Unknown User (smartin)

        Thanks Scott - does this still apply even when placed after the "Creates the issue originally" step?

        1. Unknown User (speimann@curtisswright.com)

          Steve,

          I'm not certain. 

          This is kind of a chicken and egg problem, actually.  If you try to update the values after the issue is created, then you'll miss the storage step in the post-functions. 

          Of course, you could do a secondary store on the issue values, but that might insert inappropriate audit-trail records.

          Try it and see what happens?

          I think you might be stuck writing some code into the plug-in, which copies "new" field values, rather than pre-existing values.

          Cheers!
          Scott

          1. Unknown User (smartin)

            Doesn't seem to work when I try to store the issue. I'll have another look at it in a few days when I've got more time.

            For the moment, a workaround is to use a post function to execute another transition (via script runner), make that transition go to the same status and on that one have the field copying take place. Now all I need to do is conditionally hide it so nobody can execute it from the front end, and it'll be fine.

            1. Unknown User (speimann@curtisswright.com)

              Steve,

              I can see the logic of it, but why should a post-function be able execute a transition that is otherwise hidden to the user?  That just doesn't make any sense.

              What you might do, though, is insert a transitiory state that is automatically transitioned through.  Still, I'm not sure that recursive transitions are a healthy or sane thing in JIRA.  This falls in the area of make careful experiments and find out.

              Good Luck!
              Scott

  18. Unknown User (bernard.oflynn@aegon.ie)

    We're trying to link issues across projects. Is there any way we can use this plugin to prevent the parent issue from being resolved until the linked issue in another project is resolved?

    1. You should look into the Script Runner plugin

      David.

  19. Unknown User (assistlydavid)

    I'm trying to use the "Increase value of field" function to increment a custom field called "Votes" of Number type.  However, the value is not incrementing.

    In each workflow step I have added a transition called "Vote".  The transition does not change the issue's status, it simply calls the "Increase value of field" as a post-function for the field "Votes".  I would expect the value to increment by 1 each time the "Vote" button is pressed, but the value does not change.

    I've checked that the workflow is published.  I've checked that I'm not missing the post-function.  When I check the issue's activity I simply see "David Taylor changed the status to Open of AA-ZZZZ (Testing votes)" for every button press.

    Anything I'm missing?

    1. David,
      I don't see why it shouldn't work. Anything suspicious in the logs?
      In which position did you put the post-function in the list of post-functions?
      As for the history or activity trail, it's (unfortunately) normal to see only the destination status and not the transition name. Hopefully Atlassian will fix that someday...
      David

      1. Unknown User (assistlydavid)

        I don't have access to the logs, unfortunately, as this is the hosted Jira service.  I think I figured it out, though...

        It turns out that "Views" must be some sort of reserved/built-in.  Probably for the existing and limited voting functionality.  When I created another custom field called "Customer Votes" it worked fine.  I tried recreating the "Votes" custom field and the problem persisted.

        Thanks for getting back to me.

        Cheers,

        David.

  20. Unknown User (justin.rand)

    I'm also having issues with the "Assign to Role member" post-function on the Create transition. I've added the following key/value pair in the User Properties for my selected default user:

    key= "defaultAssignee"

    value= "SAMPLE,QA Leads"

    Where SAMPLE is the key for the project and QA Leads is the role. Can you verify that my syntax is correct? I do have 2 users in the QA Leads project role, but only 1 has the key/value set.

    I currently have the post-function immediately after the "Creates the issue originally" function.

    Thanks for any help!

    -Justin

    1. Unknown User (justin.rand)

      Nevermind. It literally is "SAMPLE->QA Leads". Hope this helps someone else out! Thanks for the great plugin!

      1. Well, I thought the "->" looked like an association arrow... (tongue)

        I will update the page with an example.

  21. Unknown User (frankona)

    Is it possible to change the value of a linked issue field with some of the PostFunctions?

  22. Hi i'm trying to copy specific fields from a parent issue to a child issue using the Set Field Value from Parent post fuction.

    I'm not sure i am even using the right option for this use(Set Field Value from Parent).

    i also get this error using Set Field Value from Parent

    [Error creating issue: Could not load FunctionProvider class]

    1. Hi Jeff,

      it all depends on when (where) you are trying to copy fields from parent to child. The Set Field Value from Parent post function works only on the workflow of child issues. If you are trying to copy fields from a parent issue to all its child issues when transitioning the parent issue, this won't work.

      Also, I would need more info on the error message, but you should create a Jira issue for that in our issue tracker: https://studio.plugins.atlassian.com/browse/JMWE

      David

      1. Hi david

        what i did was 

        I added the post function on my initial transition of my child workflow.

        not my parent workflow and caused me the error.

        What more information can i provide for you?

        thx for the quick reply

        1. Caught exception while attempting to perform action 71 from workflow 37405 on issue 'WINSEV-99'
          com.opensymphony.workflow.WorkflowException: Could not load FunctionProvider class
                  at com.opensymphony.workflow.AbstractWorkflow.executeFunction(AbstractWorkflow.java:865)
                  at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1265)
                  at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:567)
                  at com.atlassian.jira.workflow.SimpleWorkflowManager.doWorkflowAction(SimpleWorkflowManager.java:312)
                  at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:505)
                  at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:513)
                  at com.atlassian.jira.web.action.issue.CommentAssignIssue.doExecute(CommentAssignIssue.java:197)
                  at webwork.action.ActionSupport.execute(ActionSupport.java:165)
                  at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:74)
                  at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:39)
                  at webwork.interceptor.NestedInterceptorChain.proceed(NestedInterceptorChain.java:31)
                  at webwork.interceptor.ChainedInterceptor.intercept(ChainedInterceptor.java:16)
                  at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:35)
                  at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:205)
                  at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:143)
                  at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:151)
                  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                  at com.atlassian.jira.web.filters.JiraLastFilter.doFilter(JiraLastFilter.java:81)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                  at com.atlassian.core.filters.HeaderSanitisingFilter.doFilter(HeaderSanitisingFilter.java:44)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                  at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46)
                  at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66)
                  at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:25)
                  at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)
                  at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)
                  at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77)
                  at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                  at com.atlassian.jira.web.filters.accesslog.AccessLogFilter.executeRequest(AccessLogFilter.java:102)
                  at com.atlassian.jira.web.filters.accesslog.AccessLogFilter.doFilter(AccessLogFilter.java:86)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                  at com.atlassian.jira.security.xsrf.XsrfTokenAdditionRequestFilter.doFilter(XsrfTokenAdditionRequestFilter.java:50)
                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
                  at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129)
                  at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)
                  at com.atlassian.jira.web.filters.PathExclusionFilter.doFilter(PathExclusionFilter.java:118)
                  at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)
          Caught exception while attempting to perform action 71 from workflow 37405 on issue 'WINSEV-99'

          com.opensymphony.workflow.WorkflowException: Could not load FunctionProvider class

                  at com.opensymphony.workflow.AbstractWorkflow.executeFunction(AbstractWorkflow.java:865)

                  at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1265)

                  at com.opensymphony.workflow.AbstractWorkflow.doAction(AbstractWorkflow.java:567)

                  at com.atlassian.jira.workflow.SimpleWorkflowManager.doWorkflowAction(SimpleWorkflowManager.java:312)

                  at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:505)

                  at com.atlassian.jira.bc.issue.DefaultIssueService.transition(DefaultIssueService.java:513)

                  at com.atlassian.jira.web.action.issue.CommentAssignIssue.doExecute(CommentAssignIssue.java:197)

                  at webwork.action.ActionSupport.execute(ActionSupport.java:165)

                  at com.atlassian.jira.action.JiraActionSupport.execute(JiraActionSupport.java:74)

                  at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:39)

                  at webwork.interceptor.NestedInterceptorChain.proceed(NestedInterceptorChain.java:31)

                  at webwork.interceptor.ChainedInterceptor.intercept(ChainedInterceptor.java:16)

                  at webwork.interceptor.DefaultInterceptorChain.proceed(DefaultInterceptorChain.java:35)

                  at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:205)

                  at webwork.dispatcher.GenericDispatcher.executeAction(GenericDispatcher.java:143)

                  at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:151)

                  at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                  at com.atlassian.jira.web.filters.JiraLastFilter.doFilter(JiraLastFilter.java:81)

                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                  at com.atlassian.core.filters.HeaderSanitisingFilter.doFilter(HeaderSanitisingFilter.java:44)

                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                  at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:46)

                  at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter$1.doFilter(DelegatingPluginFilter.java:66)

                  at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:25)

                  at com.atlassian.plugin.servlet.filter.DelegatingPluginFilter.doFilter(DelegatingPluginFilter.java:74)

                  at com.atlassian.plugin.servlet.filter.IteratingFilterChain.doFilter(IteratingFilterChain.java:42)

                  at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:77)

                  at com.atlassian.plugin.servlet.filter.ServletFilterModuleContainerFilter.doFilter(ServletFilterModuleContainerFilter.java:63)

                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                  at com.atlassian.jira.web.filters.accesslog.AccessLogFilter.executeRequest(AccessLogFilter.java:102)

                  at com.atlassian.jira.web.filters.accesslog.AccessLogFilter.doFilter(AccessLogFilter.java:86)

                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                  at com.atlassian.jira.security.xsrf.XsrfTokenAdditionRequestFilter.doFilter(XsrfTokenAdditionRequestFilter.java:50)

                  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

                  at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129)

                  at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77)

                  at com.atlassian.jira.web.filters.PathExclusionFilter.doFilter(PathExclusionFilter.java:118)

                  at com.atlassian.core.filters.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:31)

          this is my log file

          1. Let's follow this up in the Jira issue you've created.

  23. I would like the inverse of the Previous State Condition, that is, hide an action if the issue has been in specified state at least once before. My simplified scenario is as follows. I have steps "New", "In Progress" and "Chatting" with the following transitions:

    • New > Start work > In Progress
    • New > Discuss > Chatting
    • In Progress > Discuss > Chatting
    • Chatting > Start work > In Progress
    • Chatting > Continue work > In Progress

    The "Chatting > Start work > In Progress" transition should only be available if the issue has never been in the "In Progress" status before

    The "Chatting > Continue work > In Progress" transition should only be available if the issue has previously been in the "In Progress" status

    The above two transitions have different transition screens and validations, hence their separation. The "Continue work" transition can be handled with the standard Previous Status Condition. However, the "Start work" transition cannot.

    Would it be possible to modify the Previous Status Condition to have a NOT option/checkbox? That would be very useful in my case.

    1. This should be pretty straightforward. Can you create an Improvement Jira issue?

      1. Created the improvement issue JMWE-110

  24. Can I ask whether anyone has tested or had success using plugin version 2.5.1 (latest stable at time of writing) against JIRA 5.1.x standalone? I'll be conducting non production testing shortly, but was hoping my findings can be corroborated.

    Many thanks!

    EDIT:

    Even thought the plugin doesn't indicate it supports JIRA 5.1.X, it does look like there are some successes out there. Found this on the atlassian answers, and also saw this review from C Faysal

  25. Unknown User (caponez)

    Hello,

    it seems that the post-function "Transition Parent Issue" in a sub-task transition doenst work. I tried it with the name of the transition from the parent issue and later with the id. But there is no transition on the parent issue. Or am I misunderstood smth?

    Our JIRA-Version: 5.1.6

    Many thanks!!

    1. Hi,

      can I assume that:

      1. you're using real Jira "sub-tasks", not pseudo-subtasks defined by the Structure plugin?
      2. You're trying to automatically trigger a transition on the subtask's parent issue that is actually available from the parent's current status and the user triggering the transition on the subtask is authorized to trigger the parent transition as well?
      1. Unknown User (caponez)

        Hello David,

        1. yes, it is a real sub-issue from JIRA, but a custom issue- and sub-issue-type.

        2. yes, that is a transition which is availaible from the status of the parent issue. There are another transitions from this status and the "Transition parent issue" doesnt work for them too. I tested that with the admin-account and with all rights.

        What i have to type in the field "Transition parent issue"? The ID, f.e. 3, or the name, f.e. Reopen Issue, or both, f.e. Reopen Issue (3)?

        Thank you and greetings

        1. I just tried with a custom issue and sub-issue type, with Jira 5.1.8, and it worked just fine. I added the post-function to the "resolve issue" transition of the subtask workflow, specified a custom transition name ("Leave Kanban" in my test), and then created an issue and a sub-task, moved the parent issue and the sub-task to the appropriate states, and then simply transition the subtask (directly from the parent issue screen) and saw both states change at once.

          Anything in the Jira logs?

          1. Unknown User (caponez)

            Ok, now i got this working. The main things you have to know are the following steps:

            1. enter the ID of the parent transition, not the name.

            2. put the post function "Transition parent issue" to the END of the Post-functions

            After that, it works fine.

            Greetings

  26. Hi!

    I have a problem with sub-task field fill from parent task.

    I have added a new "Set Field Value from Parent" function to the "Create Issue" transition. I have chosen field.

    And when I created sub-task nothing happens. This field have stayed empty.

    What I do wrong?

    1. Hi,

      I assume you've set up this function on the "create" transition of the workflow of the subtask. And I also assume you're using real Jira subtasks, not pseudo-subtasks such as those offered by third-party plugins.

      If so, did you try moving the function up or down within the list of post-functions of the transition? Also, what type of field are you copying from and to?

      David

      1. I'm not sure about "transition of the workflow of the subtask". I have only copy of "The default JIRA workflow." And I see only "Create Issue" transition there.

        1. Then you're probably using the same workflow for normal issue and subtasks.

          And I'm talking about the list of post-functions of the create issue transition (where you added the "Set Field Value from Parent" function).

          1. Well, I use real JIRA sub-tasks.

            I have tried to move "Set Field Value from Parent" function at the 1st, 2nd and 3rd (last) place in "Post Functions" Tab of "Edit Transition" window.

            I've tried "Affect's Version" field and 2 custom fields of type: "Number Field" and "Select List".

            It's not working...

            1. Is there any error in your logs? Look for "innovalog". Also, what version of Jira and JMWE are you using?

              Finally, it'd be best if you created a support request on the "Issues" tab of this page instead of using comments here.

  27. Unknown User (bvgeer)

    I am trying to get the example working: Copying the user property: "Company" to a text field "Company Groupname". Somehow the postfunction during creating the issue does not work, or at least it does not copy the result into the selected field.

    I added in the workflow at the "Create" step the post function "The value of field Company Groupname will be set to the value of the user's Company property.".
    As there is not much room for errors, I am wondering what is wrong. I moved that function from the first to the last line also, no difference. Still an empty variable.
    The workflow is published.

    • JIRA 4.3.3, 
    • Misc Workflow Extensions Version: 2.4.1
    1. Did you try putting the function just after the "Creates the issue originally" built-in function (not at the end)?

      Also, I assume you've checked that the user has a custom property named "Company" (in the Jira sense)?

  28. Is it possible to copy a value from Global Rank into a text/number field? If you have any pointes it would be very helpful!

    1. Have you tried the Copy from field to field post function to copy from "Rank" to your custom field?

  29. It would useful to add a section to this page about troubleshooting. For example, the log4.properties information to use.