- attached Close-Issue-Post-Functions.jpg
Post function (Issue status (delayed writing)) fails to get value
I am using the JIRA Workflow Toolbox 2.1.34 with custom Sub-tasks. The custom sub-task uses Blocked and Is Blocked By to force a Sub-task not to move status values. In the Close Issue Post function I have - Value of field Ephemeral string 1 in current issue will be copied to field Issue status (delayed writing) in linked issues or subtasks filtering by:
When the sub-task is Closed, it should move the status in any Sub-task that has a valid Is Blocked By Issue Link.
This does not work anymore and I get the error in the Jira logs - 2015-08-17 09:52:25,913 ajp-bio-8009-exec-9 WARN jirauser 592x405x1 1dpu27h 1.2.1.5 /secure/CommentAssignIssue.jspa [plugins.workflowToolbox.shared.GeneralizedField] Can't provide value to field Issue status (delayed writing) because getValue() method don't know how to get the value.
Comments (86)
-
reporter -
reporter - attached Ready-Issue-Post-Functions.jpg
Here is the Ready Issue Post Function. This is the first part of the Workflow to set Parent's Ephemeral string 1
-
reporter - attached Failure-Of-Status-Assignment.jpg
Here is the failure of a Conditional Sub-task, the Status should have been set to Assigned after the linked Sub-task is Closed
-
reporter Everything use to work with JIRA Workflow Toolbox 2.1.20. Jira version is 6.3.5
-
repo owner Andre,
Please update your 3th post-function in transition "Close Issue" replacing "Assigned" with "Assigned {delay=1000}" as I show in the screenshot:
Fidel
-
reporter - attached error-after-change-log.txt
I added the Assigned {delay=1000}, however I get an Red exclamation Point. See log error
-
reporter - attached Error-After-Change.jpg
-
repo owner Please, try version 2.2_beta_1 and with the original value, i.e. "Assigned".
-
reporter Tried version 2.2_beta and changed the org value back to Assigned. Still getting the error - Can't provide value to field Issue status (delayed writing) because getValue() method don't know how to get the value.
-
repo owner Hi Andre,
In your configuration of "Write field on linked issues or subtasks" post-function, you are only writing intro sibling subtasks and not into "is blocked by" or "blocks" linked issues.
I think that you should edit the configuration of that post-function, and include "blocks" issue link. The configuration of your post-function shouldn't have changed due to add-on version update.
Please, try it and tell me how it works.
Can you please also tell me if the problem is solved simply reinstalling version 2.1.20 again?
-
reporter I tried to uninstall the plugin and re-install the 2.1.20 version. And this works without any issue. I'll try the beta version and set the blocks in the post function.
-
reporter Tried the folllowing -
Value of field Ephemeral string 1 in current issue will be copied to field Issue status (delayed writing) in linked issues or subtasks filtering by: Inward issue link types: none Outward issue link types: blocks. Subtasks won't be written. Sibling subtasks fulfilling conditions on issue type, status and project will be written. Issue types: Conditional-task. Statuses: Open and Reopened. Linked issues or subtasks may belong to any project. This feature will be run as user in field Current user.
Still - Can't provide value to field Issue status (delayed writing) because getValue() method don't know how to get the value
-
repo owner Andre,
I think that the error message in the log has nothing to do with the problem. I think that is should also appear with version 2.1.22? I think that it's due to a not very well designed output message to the log file, but is not an actual problem.
I need some more information:
-
I don't understand what role do transition "Ready Issue" in this issue and post-function "Set field as a function of other fields" play in this bug. Can you please explain me why have you included it in the description of the bug?
-
Can you please provide me screenshots of conditions and validations tab of transition "Ready Issue"?
-
-
repo owner I will be available at Skype for 30 minutes, until 22:30 UT approximately. We can have a screen share to see the problem in direct. My Skype user is "fidel100r".
-
reporter The Transition Ready Issue, is a custom workflow step. We added this to go between Open & In Progress. The Workflow Status goes from Open to Assigned to In Progress to Closed Ready Issue is the transition name.
I can do a WebEx tomorrow, I am current in the PST (Pacific, Los Angeles) time zone. I am available at 7:30 - 3:30 PST.
-
repo owner Andre,
Can you please tell me if HD-99767 and the issue whose screenshot you attached to the issue (you didn't include the issue key), are both subtask's of a same parent?
Can you please attach screenshots of conditions and validations tab of transition "Ready Issue"? I think that a modification on the behavior of a condition or validation might be the reason of the problem.
I will be available for a WebEx tomorrow.
Thanks
-
reporter - attached Condition-Sub-Task-Workflow.jpg
Workflow 1
-
reporter Workflow 2
-
reporter Workflow Ready Issue
-
reporter Workflow Close Issue
-
reporter Here is the WebEx information. Please let me know when you are ready and I will start the WebEx session.
Topic: Jira Workflow Issue
Meeting Number: 629 106 029 Meeting Password: tgCMmt6M
Go to https://thezenith.webex.com/thezenith/j.php?MTID=mb0cf35bcffa715220f537e7b2b531e77
US TOLL FREE: +1-855-749-4750 US TOLL: +1-415-655-0001
Access code:629 106 029 Global call-in numbers: https://thezenith.webex.com/thezenith/globalcallin.php?serviceType=MC&ED=412335947&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf
-
repo owner Hi Andre,
I'm very sorry, but finally today I'm not able to have the meeting. Please, give me some time to study in detail all the information you have attached to the issue, and I will give you my feedback as soon as possible.
Anyway, tomorrow I will be able to have the meeting if it keeps being necessary.
Thank you for your patience.
Fidel
-
repo owner Andre,
Please, do the following changes in your workflows, and let me know if this solves the problem:
-
Restore configuration of "Write field on linked issues or subtasks" post-function to initial status, i.e. uncheck issue link types "blocks" and "is blocked by".
-
Remove 5th post-function in transition "Close Issue". I mean post-function "Copy a parsed text to a field" writing "B" into "Parent's ephemeral string 1".
Don't use the beta version, but 2.1.34.
Thanks for your patience,
Fidel
-
-
repo owner Hi Andre,
Did you tried the 2 changes I described in my previous post?
Regards,
Fidel
-
reporter Hi, I removed the beat version, replaced it with 2.1.34 Restored the Configuration by un-checking Blocks and is blocked by Removed the 5th post function in Close Issue transition.
Tested again, and some of the Sub-tasks are moving to the next status and some are not. See the attached image. I am still getting the error in the log that it cannot get the value.
Andre
-
reporter -
repo owner Are those issues that don't move blocked by another issues by links "is blocked by"?
Can you please check whether transition "Ready Issue" is shown in issues that not moving to "Assigned" status? I want to know if you could transition these issues manually.
Can we have a screen share in 30 minutes to 1 hour?
-
reporter Yes, Here is the Webex session.
Topic: Jira Issue Date: Friday, August 21, 2015 Time: 12:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 620 974 010 Meeting Password: nP9BdvxC
- Go to https://thezenith.webex.com/thezenith/j.php?MTID=m075cc471722e3c9e721049043b6f23dd
- Enter your name and email address.
- Enter the meeting password: nP9BdvxC
- Click "Join".
To join the audio conference only
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. US TOLL FREE: +1-855-749-4750 US TOLL: +1-415-655-0001
Access code:620 974 010 Global call-in numbers: https://thezenith.webex.com/thezenith/globalcallin.php?serviceType=MC&ED=413279782&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf
-
repo owner Can we have the conference at 13:00 PST?
-
reporter Sure, i'll leave the meeting open
-
repo owner Hi Andre,
Please, try installing version 2.2_beta_2 and doing the following changes in your workflows:
1) Transition Ready Issue: replace "Condition based on regular expression" with "Boolean condition with math, date-time or text-string terms" using the following configuration:
Boolean expression used is:
!isJwtTriggeredTransition() OR {00115} = null OR {00057} - {00115} > 2 * {SECOND}
2) Transition Ready Issue: Replace post-function "Copy a parsed text to a field" with "Mathematical and date-time expression calculator" using the following configuration:
isJwtTriggeredTransition() ? {00057} : 0
3) Transition Close Issue: Remove post-functions 2 and 5 as shown in the following screenshot:
Configuration of post-function "Write field on linked issues or subtasks" is also the original, i.e., leaving all the issue link types unchecked.
Please, let me know if this configuration fixes your problem.
Regards,
Fidel
-
reporter Hi, I updated the plugin version and made the changes as requested.
After I Closed the 1st sub-task, only one Sub-task moved to Assigned. The rest are still at Open.
-
repo owner Andre,
Sorry, I thought you wanted to move only one issue each time.
To achieve you're desired behavior, please do the following:
- Reinstall version 2.1.34.
- Remove condition and post-function from transition Ready Issue.
Leave transition Close Issue with its current configuration, i.e., with only two post-funcions.
Please, tell me how it works.
-
reporter Re-installed 2.1.34
Removed the Condition and the Post Function in Ready Issue.
All remaining sub-tasks are still in the Open status. None of them moved to Assigned.
-
repo owner Please, try it after installing version 2.2_beta_2.
-
reporter I re-installed 2.2_beta_2
Test 1 - After the transition of the 1 sub-task. Most of the Blocked by sub-tasks went to Assigned. (A couple were left at Open)
Test 2 - After the transition of the 1 sub-task. Most of the Blocked by sub-tasks went to Assigned. (A couple were left at Open, however different sub-tasks than the first test)
-
repo owner Please, try version 2.2_beta_3.
-
reporter Installed beta 3, and I am having the same results. Not all sub-tasks move to Assigned
-
repo owner Isn't it possible that these issues are blocked by issue links "is blocked by"?
-
reporter It is set with "is blocked by", however the Sub-task that is blocking it has already been moved to Closed, and this should have changed the status from Open to Assigned. It seems as though it is skipping some sub-tasks
-
repo owner Can you please try these two other versions of the plugin?
One question: Is the issue you are closing manually the one that is blocking the issues that are not moving to "Assigned" status?
Thanks for your collaboration.
-
reporter 2.1.32 seems to be working. Updates to the sub-tasks are moving to Assigned
2.1.33 doesn't work at all, No Sub-tasks are moving to Assigned.
-
reporter Also, with 2.1.32, I am not getting those errors in the logs -
plugins.workflowToolbox.shared.GeneralizedField (delayed writing) because getValue()
-
repo owner Are you using the configuration with no condition and post-function at "Ready Issue" transition, and only 2 post-functions in "Close Issue" transition?
Please, move the 2 post-functions in "Close Issue" transition to first and second positions in execution order, i.e., before "Set issue status to the linked status..." post-function.
Then, please, try version 2.2_beta_2 removing the validation in "Ready Issue" transition, and tell me if all the issues are moving to "Assigned" status.
-
reporter - attached Current-Ready-Issue-Transition.jpg
Yes, here is the Ready Issue settings
-
reporter - attached Current-Close-Issue-Transition.jpg
Yes, here is the Close Issue settings
-
reporter The plugins were tested with these settings (Ready & Close). The only one that currently works without the issue is 2.1.32
-
repo owner Hi Andre,
Please do the following:
- Install version 2.2_beta_2.
- Move the 2 post-functions in "Close Issue" transition to first and second positions in execution order, i.e., before "Set issue status to the linked status..." post-function, as shown:
Now, try the workflow again.
IMPORTANT: If you observe that some subtasks remains in "Open" status, please refresh your browser, and observe whether those issues have moved to "Assigned" status.
Each delayed issue transition is executed in its own thread. If you have many subtasks, some of those threads might have not yet finished execution, and at first glance you see subtasks still in old status.
-
reporter Version 2.2_beta_2 is installed. Moved the 2nd post function as described in the picture. Ran the test again, waited 5 mins and refreshed the screen Still having an issue with some of the Sub-tasks that are suppose to move from Open to Assigned (After the first sub-task is closed)
-
repo owner Hi Andre,
I have tried your same configuration moving 30 subtasks at the same time without problems. I only have observed the necessity to wait some 5 seconds for all the issues to be moved to target status. I have used JIRA 6.4.10 and JIRA Workflow Toolbox 2.1.34 and 2.2_beta_2 for this testing. Both version of the plugin worked OK.
How many subtasks do you have in your parent issues?
Which version of JIRA are you using?
Can you please do the following:
1) Set logging level to DEBUG for package com.fca.jira.plugins.workflowToolbox
Administration > Logging & Profiling > Configure logging level for another package > Package name: com.fca.jira.plugins.workflowToolbox and Logging Level: DEBUG
2) Repeat the test of the workflow
3) Make the log file available to me. You can send it to support@workflowarts.com.
I will be available for a video conference in 2 hours if necessary.
-
Hello, i don't want to complicate this issue by segwaying but i believe i am suffering the same (or similar) issue. This only started occurring since the latest update. We are seeing heaps of these in the logs.
/secure/WorkflowUIDispatcher.jspa [plugins.workflowToolbox.shared.GeneralizedField] Can't provide value to field Issue status (delayed writing) because getValue() method don't know how to get the value.
Our post functions transition linked issues into different statuses using the same post function mentioned above. Previously everything was working flawlessly now they work in some scenarios and not in others. Can someone please let me know how to revert to the previous version?
-
Just an update, i figured out how to revert the plugin, i can also confirm it doesn't work in 2.1.33 but it works fine in 2.1.32 and the logs entries disappear.
-
reporter - attached Debug_log.txt
Here is the log file. HD-100518 & HD-100526 should have been set to Assigned, however these are at Open
-
reporter Hi Ben, Yes, 2.1.32 does work for me as well without any issues or log entries as well.
-
repo owner The mechanism involved in delayed execution of transitions was fully redesign in version 2.1.33, in order to avoid a problem that was appearing when a big number of issue transitions where triggered at the same time.
It seems that this redesign has some king of collateral damage. The thing is that I cannot reproduce your problems. I'm thinking of same changes in the part of the plugin involved in delayed transitions, that perhaps may solve the problem, but I'm not comfortable with the idea of changing actual code before knowing exactly the cause of your problems.
Your collaboration is very important to find out the cause of the problem, and finally resolve it, so please, be patience.
For that reason, Ben, I ask you to create a new issue in order to track your problem, and explain me the details of your configuration that is suffering the problem. Please, attach some screenshots of the configuration of the post-function that is triggering delayed execution, and tell me the number of issues being triggered, the version of JIRA your are using, and any other detail that you think might be relevant.
Thank you very much.
-
repo owner Andre,
Those 2 issues seem to be blocked by a validation not being satisfied. In the log it can be read:
[plugins.workflowToolbox.shared.IssueTransitionManager] *** EXECUTION OF TRANSITION "Ready Issue" ON ISSUE HD-100518 AT STATUS "Open", HAS FAILED DUE TO A VALIDATOR NOT BEING SATISFIED.
Can you please tell which issues are HD-100518 and HD-100526 issues linked with?
Are they being blocked by current issue (i.e., transition being closed)?
-
reporter - attached All-Sub-tasks-Blocked.jpg
These are only blocked by HD-100516. This is the first Sub-task and the only Sub-task that I changed to Close.
-
repo owner Andre, are HD-100518 and HD-100526 the only issues blocked by HD-100516? Or are there more issues blocked by that issue?
-
reporter - attached HD-100516.jpg
Here is all of the Sub-tasks links from HD-100516
-
reporter - attached HD-100518.jpg
Here is HD-100518, it should have moved to Assigned.
-
Ok i will create a new issue with some more information into it then, hopefully tomorrow as its hard to get a time when i can install the new plugin as our system gets used most of the day.
-
repo owner -
reporter - attached ErrorLog-4.txt
I did some test and it looks like it is moving the Issues to Assigned. However the 1st sub-task doesn't refresh the statuses on screen. I need to do a F5 screen refresh to see that the Status changes have occurred. Plus I am still getting errors in my logs (see attached text doc). With 2.1.32 I didn't get any errors and the screen auto-refreshed.
-
repo owner Hi Andre,
Thanks for the testing. Can you please test 2.2_beta_5 and let me know if issues pass to "Assigned" status and UI is correctly refreshed.
The warn message in the log file will also be fixed in next version of the plugin.
Thanks, for your collaboration.
Fidel
-
reporter - attached Beta-2.2.5.jpg
No, this is still the screen from 2.2.5
-
reporter - attached Beta-2.2.5.jpg
No, this is still the screen from 2.2.5
-
reporter - attached Beta-2.2.5.jpg
No, this is still the screen from 2.2.5
-
reporter - attached Beta-2.2.5.jpg
No, this is still the screen from 2.2.5
-
repo owner This is a completely unexpected behavior: only one issue has passed to "Assigned" status.
Can you please set DEBUG mode for package com.fca.jira.plugins.workflowToolbox, repeat the test and attach the log file for that behavior?
That screenshot are actual issue statuses, or are due to unrefreshed UI?
-
reporter - attached Old Plugin vs New Plugin.pdf
I've attached a PDF document of the User experience. This document compares both the old version of the plugin and the new version. The user experience works the same up to 2.1.32 of the plugin.
-
reporter - attached Log-Debug-Number-2.txt
Here is the 2nd debug log
-
repo owner Hi Andre,
Thanks for all that detailed information. Now, I have found the cause of UI not being auto-refreshed. I have fixed it, but I still have some doubts about the cause of validation not being satisfied in some cases.
Please, try these two versions and let me know how they work: 2.2_beta_6 and 2.2_beta_7.
Thank you very much for your collaboration.
Fidel
-
reporter - attached Debug-Log-3.txt
Tried both versions and both versions fail to transition any sub-task from Open to Assigned. All sub-tasks remain at Open.
-
repo owner Hi Andre,
If version 2.2_beta_4 didn't failed to move issues (it was failing in version 2.2_beta_3), I don't find any reasonable cause for later versions keep failing to do it, since the modification in the code that fixed it from version beta_3 to beta_4, is in later versions.
At this moment, the only reasonable cause I can think of, is that the validation is blocking the transitions legitimately.
If you don't mind, I would like to see the failure in direct. Can we have a screen share today at 11:30 PST?
-
reporter Sure, here is the WebEx Information -
Topic: Jira Issue Date: Monday, August 31, 2015 Time: 11:35 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 624 382 421 Meeting Password: bQcuVxM7
Please click the link below to see more information, or to join the meeting.
To join the online meeting
- Go to https://thezenith.webex.com/thezenith/j.php?MTID=m37f955db87de50845ffc8fe714095b41
- Enter your name and email address.
- Enter the meeting password: bQcuVxM7
- Click "Join".
To join the audio conference only
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. US TOLL FREE: +1-855-749-4750 US TOLL: +1-415-655-0001
Access code:624 382 421 Global call-in numbers: https://thezenith.webex.com/thezenith/globalcallin.php?serviceType=MC&ED=417246377&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf
-
repo owner Andre,
Can you please try the following two versions?
-
2.2_beta_8 : exactly the same code as beta 4 (250 ms latency), except for auto-refresh bug which is fixed.
-
2.2_beta_9 : 500 ms latency for first delayed execution, and extended log file output for diagnosing the problem.
Please, set DEBUG mode for package com.fca.jira.plugins.workflowToolbox, and attach the log file.
Thanks.
-
-
repo owner Hi Ben, can you please try version 2.2_beta_7 and tell me if it solves your problem?
Thanks
-
reporter - attached 2-2_beta_8.txt
2.2_beta_8 - Closed the 1st sub-task and none of the blocked sub-tasks moved to assigned. All remain at Open. See attached debug log
-
reporter - attached 2-2_beta_9.txt
Same for 2.2_beta_9 - Closed the 1st sub-task and none of the blocked sub-tasks moved to assigned. All remain at Open. See attached debug log
-
repo owner Andre,
This is the most strange case I have ever found. It's hard to admit, but at this moment I'm completely lost. I can't imagine a reason for that validator not being satisfied.
Can you please try replacing "Validation on linked issues" with "Boolean condition with math, date-time or text-string terms" using the following configuration:
Boolean expression is:
count(linkedIssues("is blocked by")) = count(filterByStatus(linkedIssues("is blocked by"), "Cancelled, Closed"))
Please, test the validator manually to confirm that it works as expected. Then, try version 2.2_beta_9, and let me analyze the log file, please.
Thank you.
-
Hi, i will give it a test tonight and create a new issue with further information.
-
repo owner Hi Andre, I have managed to reproduce your problem. This will enable me to investigate the cause and fix it. I hope I will have a solution soon.
-
repo owner Hi Andre,
I think version 2.2_beta_11 is fixing the problem definitively.
I would like to release this version as soon as possible, since this bug is really important. I keep waiting for your confirmation that the issue is solved,
Thanks.
-
repo owner The problem is fixed in version 2.1.35. Please, update to the new version and confirm resolution closing the issue. Thanks.
-
reporter Good morning,
It looks like 2.1.35 has fixed the issue and the intended workflow is functioning properly.
Thanks in advance, Andre
-
repo owner - changed status to resolved
Thanks for the resolution confirmation, Andre. I close the issue. Please, reopen it in case you find the problem persist.
- Log in to comment
This is the Close Issue Post Function