Community
Participate
Working Groups
I am trying to close or resolve issues in a repository that has customized workflow. When I submit an error dialog that show a JIRA system error is displayed: System Error A system error has occurred. If this problem persists - please notify your JIRA administrator of this problem. If you are an administrator, please try submitting this problem via the Support Request Page Else, please create a support issue on our support system at http://support.atlassian.com with the following information: 1. a description of your problem 2. cut & paste the error and system information found below 3. attach the application server log file ( /spare/jira/atlassian-jira.log ) Cause: java.lang.IllegalArgumentException: No workflow action with id '5' available for issue CORE-204 Stack Trace: [hide] java.lang.IllegalArgumentException: No workflow action with id '5' available for issue CORE-204 at com.atlassian.jira.workflow.WorkflowTransitionUtilImpl.getActionDescriptor(WorkflowTransitionUtilImpl.java:135) at com.atlassian.jira.workflow.WorkflowTransitionUtilImpl.getFieldScreenRenderer(WorkflowTransitionUtilImpl.java:212) at com.atlassian.jira.web.action.issue.CommentAssignIssue.getFieldScreenRenderer(CommentAssignIssue.java:98) at com.atlassian.jira.web.action.issue.CommentAssignIssue.doValidation(CommentAssignIssue.java:152) [...]
I have created a project with a customized workflow on the test server. Resolving issues displays the following message: Workflow Action Invalid It seems that you have tried to perform a workflow operation (Resolve Issue) that is not valid for the current state of this issue (Open). The likely cause is that somebody has changed the issue recently, please look at the issue history for details. Please refresh the issue and try again.
Steffen, so what do you think we should do about this? We can probably call IssueService.getAvailableActions() [1], but I am not sure where should we do that, because available actions are shown at the time editor is created and we don't have lazy way of retrieving them. [1] http://tinyurl.com/2557lq
For Trac I get the actions when downloading task data. This is not going to map well to the API changes where we retrieve all task information when synchronizing queries though. We should also invoke JiraSoapService.getFieldsForEdit() and only make these editable.
(In reply to comment #3) > For Trac I get the actions when downloading task data. This is not going to map > well to the API changes where we retrieve all task information when > synchronizing queries though. Right. At this point retrieving those things when downloading task data is not an option, because it will require too many roundtrips to the server. So, I am thinking to do it when editor will be opening, but it should be somehow background/lazy task, so user can browse trough issue while that data is loaded and can be cached locally (I am not yet not sure where exactly to store this stuff)
That needs to go into the task data. It'd be great if we could get this lazily when the editor is opened but how we can gracefully update the editor when the information becomes available?
(In reply to comment #5) > but how we can gracefully update the editor when the > information becomes available? That is why I added Mik and Rob to CC list. Technically there should be no issues, but it will require some refactoring in the task editor. Another thing is how to know when that data is already downloaded or when it need to be refreshed (i.e. both editable fields and available actions can be changed after issue is updated/status changed). Though they could be also changed if project configuration modified on the server side. So, I wonder if we need to trigger that refresh when manual refresh is called from the editor (but probably not when issues refreshed from the task list view).
Created attachment 68849 [details] work in progress Rob, Steffen, can you please review this patch? It mostly affecting jira stuff, but I had to make small changes in AbstractRepositoryTaskEditor to make it easier to deal with for this use case. I've used hidden marker in taskData to indicate that taskData need to be updated from repository. Then I run background job to fetch stuff from repository and only after that job completed, sections Attributes and Actions will be populated. The work is not done yet and I need those canges to be applied to AbstractRepositoryTaskEditor before I can finish this. But I can already see some custrom attributes for jira tasks.
Created attachment 68850 [details] mylar/context/zip
I applied the patch as not to hold up progress, but did not review. Bootsrapping onto it now. Rob: please take a look at the changes to AbstractRepositoryTaskEditor in the patch.
Just noticed that the patch caused compile errors, had to back it out. Severity and Description Path Resource Location Creation Time Id The return type is incompatible with AbstractRepositoryTaskEditor.createAttributeLayout(Composite) com.tasktop.email.ui/src/com/tasktop/email/ui/editor AbstractNewEmailTaskEditor.java line 140 1180257028175 866048
(In reply to comment #10) Huh?! com/tasktop/email/ui/editor/AbstractNewEmailTaskEditor That one I definitely won't be able to fix for you.
My mistake, not seeing straight after a 24 hour flight. Patch applied.
Thanks Mik. Though we may need to mention this in the porting guide, in case someone overwritten that protected method like in that editor of yours...
Yes, please add that note to the porting guide, I meant to mention that before committing bug forgot. All changes to public signatures of non-internal classes should be adding to the porting guide by the contributor of the change.
I like the approach of displaying the editor right away and updating it as more information becomes available. This could be useful for Trac as well and we there might be some potential for generalization in the API. I don't think it is right to get information from the repository and update the attributes in JiraTaskEditor.createFormContent(). This should all be part of ITaskDataHandler.getTaskData() and done by the background synchronization that is triggered when the editor is opened. Rob, we need to update the QueryHitCollector API to accept TaskData, so we can have "light-weight" synchronization for queries and do the full synchronization when needed.
(In reply to comment #15) > I don't think it is right to get information from the repository and update the > attributes in JiraTaskEditor.createFormContent(). This should all be part of > ITaskDataHandler.getTaskData() and done by the background synchronization that > is triggered when the editor is opened. To make that work we'll need significant fixes on the editor, so it won't require user to push "refresh" button to pickup those changes after synchronization.
Created attachment 68896 [details] AbstractRepositoryTaskEditor cleanup Mik, Rob, can you please apply this patch. I think it does make sense to create layout outside of the attributes section method.
Steffen, I've committed quite massive change for Jira task editor. Mainly for the Attributes section, so it can show custom fields, and can render field types (dropdown, multiselect, textfield and textarea). Can you please try it if you'll have chance. This stuff took me quite while to straighten, so I haven't got to the editor actions yet. There is an issue I am not sure how to address with current task data API. I need to store some field after fetching missing data from server, but I can't see any API for that. See job inside createFormContent() method. Maybe like you said we can move that stuff into the task data handler, but it probably require some refactoring in the sync manager, that isn't quite clear to me right now. Rob, Mik, any thoughts?
I agree with Steffen, this shouldn't be done in the editor but rather as part of the task synchronization. Updates to task data (upon save) should result in notification which in turn will lead to the editor refreshing. Is there no way we can revert back to the option of getting the necessary data when it is normally retrieved (synch) albeit at the expense of more trips?
(In reply to comment #19) > I agree with Steffen, this shouldn't be done in the editor but rather as part of > the task synchronization. My current problem with that approach is that I need to check if missing data already fetched or not before opening editor. If data is missing I need to kick special type of synchronization. That separate synchronization should be also kicked when main task data changed (i.e. issues status got changed). > Updates to task data (upon save) should result in > notification which in turn will lead to the editor refreshing. In my understanding editor will ask user to push "refresh" button and I don't think it makes sense, because he'll have to push it for every new editor. Can I make editor refresh without that request? > Is there no way we can revert back to the option of getting the necessary data when it is > normally retrieved (synch) albeit at the expense of more trips? I am not sure what you mean. Currently it only done in JIRA editor and it pospone rendering of Attributes and Actions sections until those special attributes are fetched from the server. So user still can read summary and task description. Adding that fetch into a regular sync will slow down synchronization a lot, because we'll have to to N+1 trips to jira server instead of one (or N*3 if we are doing separate round trips now).
(In reply to comment #20) > > Updates to task data (upon save) should result in > > notification which in turn will lead to the editor refreshing. > > In my understanding editor will ask user to push "refresh" button and I don't > think it makes sense, because he'll have to push it for every new editor. Can I > make editor refresh without that request? Perhaps we could add an additional parameter to check so that this manual refresh can be bypassed. Ie. if(updateInProgress) refresh editor now vs. prompt user > > > Is there no way we can revert back to the option of getting the necessary data > when it is > > normally retrieved (synch) albeit at the expense of more trips? > > I am not sure what you mean. Currently it only done in JIRA editor and it > pospone rendering of Attributes and Actions sections until those special > attributes are fetched from the server. So user still can read summary and task > description. > > Adding that fetch into a regular sync will slow down synchronization a lot, > because we'll have to to N+1 trips to jira server instead of one (or N*3 if we > are doing separate round trips now). Okay so performance is an blocker to doing this up front. Have you tired saving via RepositorySynchronizationManger.saveIncoming() and calling refresh on the editor?
(In reply to comment #21) > Perhaps we could add an additional parameter to check so that this manual > refresh can be bypassed. Ie. if(updateInProgress) refresh editor now vs. prompt > user Additional parameter where? > Okay so performance is an blocker to doing this up front. Have you tired saving > via RepositorySynchronizationManger.saveIncoming() and calling refresh on the > editor? I've tried TasksUiPlugin.getSynchronizationManager().saveOutgoing(repositoryTask, changedAttributes) saveIncoming() will probably create incoming marker and will mark attributes as changed. I need to save metadata field I've added into those attributes, but I don't need to flip incoming marker for those fields that only had matadata changed.
(In reply to comment #22) > I've tried > TasksUiPlugin.getSynchronizationManager().saveOutgoing(repositoryTask, > changedAttributes) > saveIncoming() will probably create incoming marker and will mark attributes as > changed. I need to save metadata field I've added into those attributes, but I > don't need to flip incoming marker for those fields that only had matadata > changed. I think perhaps what you want is TasksUiPlugin.getDefault().getTaskDataManager().setNewTaskData(taskHandle, taskDateYou'veUpdated). Followed by a manual call to refresh the editor.
(In reply to comment #23) > I think perhaps what you want is > TasksUiPlugin.getDefault().getTaskDataManager().setNewTaskData(taskHandle, > taskDateYou'veUpdated). > Followed by a manual call to refresh the editor. That may work, except the warning: Discouraged access: The method setNewTaskData(String, RepositoryTaskData) from the type TaskDataManager is not accessible due to restriction on required project org.eclipse.mylar.tasks.core
Yes, this is currently internal. If getting and updating becomes the norm for TaskData outside of the standard synchronization jobs perhaps this api should be public.
As an experiment I moved those additional calls to jira right into JiraTaskDataHandler.getTaskData() method. BTW, Steffen, we currently have to do an extra call to convert id to key. When synchronizing queries the following code always fall to server.getIssueById(taskId), which will call server.getIssueByKey() internally. Maybe we should populate Issue instance from the object returned by soap call? int id = Integer.parseInt(taskId); ITask task = TasksUiPlugin.getTaskListManager().getTaskList().getTask(repositoryUrl, "" + id); if (task instanceof JiraTask) { JiraTask jiraTask = (JiraTask) task; return server.getIssueByKey(jiraTask.getTaskKey()); } else { return server.getIssueById(taskId); }
When the query hit to task refactoring is complete the lookup should succeed in most cases but if we can assure backwards compatibility I am all for migrating to the SOAP API (just don't delete "old code").
(In reply to comment #27) > When the query hit to task refactoring is complete the lookup should succeed in > most cases but if we can assure backwards compatibility I am all for migrating > to the SOAP API (just don't delete "old code"). I am not suggesting to completely migrate to SOAP, because RSS feed allows to fetch multiple issues in one server round trip (I hope you'll made that refactoring to load taskdata). But for this case we have issue data from SAOP and can populate issue without re-requesting same issue trough RSS. This is screwed mainly because we have used JIRA ids instead of keys everywhere.
Good point (although there is a call in JiraSoapService to retrieve multiple issues with a single call). I also suspect that RSS is faster than SOAP. I remember Jason mentioning that XML-RPC calls are significantly faster than SOAP. BTW, currently we do a login and logout for each web session. Do you think it could speed things up to re-authenticate only when a session times out?
Eugene: fyi, as part of the AbstractQueryHit removal I've added RepositorySychronizationManager.saveOffline(AbstractRepositoryTask task, RepositoryTaskData taskData). Still not committed yet as I have a large number of unit tests to refactor.
Steffen, I've committed quite massive refactoring for JIRA's data handler and editor. It should now work for any custom workflow actions (except those that require mandatory custom attributes). Please take a look when you'll have chance.
Created attachment 69663 [details] mylar/context/zip
(In reply to comment #28) ... > This is screwed mainly because we have used JIRA ids instead of keys everywhere. I realize that it still may be awkward for the JIRA connector, but this policy is important because IDs are a robust identifier for JIRA issues and keys are not (a key can change over the lifetime of an issue). Several parts of the Mylar framework rely on the repository+ID being a GUID for a task.
(In reply to comment #33) > I realize that it still may be awkward for the JIRA connector, but this policy > is important because IDs are a robust identifier for JIRA issues and keys are > not (a key can change over the lifetime of an issue). Several parts of the > Mylar framework rely on the repository+ID being a GUID for a task. Mik, it is not just awkward, it is practically insane and provide absolutely no benefits, especially because most of the JIRA remoting API is manipulating with keys and not issue ids. Besides, key can only change if issue moved into some different project (relatively rare occasion), so in most common setups (unless you have some crazy query that shows all issues from all projects), that changed issue will immediately jump into the archive category.
I get an HTML error from JIRA when I try to close an issue (see below). Note that advanceIssueWorkflow() does not use the correct URL. It's a simple fix (I can't commit this since I have other outgoing changes): PostMethod method = new PostMethod(baseUrl + "/secure/CommentAssignIssue.jspa"); System Error A system error has occurred. If this problem persists - please notify your JIRA administrator of this problem. If you are an administrator, please try submitting this problem via the Support Request Page Else, please create a support issue on our support system at http://support.atlassian.com with the following information: 1. a description of your problem 2. cut & paste the error and system information found below 3. attach the application server log file ( /spare/jira/atlassian-jira.log ) Cause: java.lang.NumberFormatException: For input string: "" Stack Trace: [hide] java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:424) at java.lang.Long.(Long.java:671) at com.atlassian.jira.issue.fields.AbstractVersionsSystemField.getRelevantParams(AbstractVersionsSystemField.java:115) at com.atlassian.jira.issue.fields.AbstractOrderableField.populateFromParams(AbstractOrderableField.java:132) at com.atlassian.jira.web.action.issue.CommentAssignIssue.doValidation(CommentAssignIssue.java:162) at webwork.action.ActionSupport.validate(ActionSupport.java:373) [...]
(In reply to comment #35) > I get an HTML error from JIRA when I try to close an issue (see below). > > Note that advanceIssueWorkflow() does not use the correct URL. It's a simple > fix (I can't commit this since I have other outgoing changes): > PostMethod method = new PostMethod(baseUrl + > "/secure/CommentAssignIssue.jspa"); Does this fixes the issue or there is something else?
No, this does not fix the JIRA exception. I tried uncommenting the code in advanceIssueWorkflow() that submits the fix version but it did not help.
I now get the same error when i try to resolve issues in projects with standard workflows. You can reproduce this using the repository on mylar.eclipse.org .
Steffen, I committed some cleanup for submission code. It now correctly sets required fields and seem to work for me on mylar.eclipse.org
Created attachment 70246 [details] Screenshot of operations I have successfully tested it with standard and customized workflows. This is really cool. Thanks for resolving this Eugene!
Thanks Steffen. Though there are couple things that we may need to look at before closing it. First of all list of available operations don't available to guests and I just catching exception there. So, still need to test how comment posting is working on projects at the codehaus and spring jira trackers. Another thing is that current RepositoryOperation instance only allow one additional property (like assignee and resolution on your screenshot). But for jira we can actually have more then one property (i.e. resolve operation also allows to reassign and specify custom fields, say for time tracking). I've been suggesting if for some time to move this UI complexity into submission wizard. So, "leave as..." would be simple (and maybe also reassign), and for everything else user would need to use submission wizard that would provide all those options.
> First of all list of available operations don't available to guests and I just > catching exception there. So, still need to test how comment posting is working > on projects at the codehaus and spring jira trackers. I should work when you use JiraClient.addCommentToIssue() instead of JiraClient.updateIssue().
Opened bugs for remaining issues: bug 203166: Fix retrieving list of available operations with guest account bug 203168: add submission wizard to task editor Marking this bug as resolved.
