Community
Participate
Working Groups
When updating a Jira bug using the local task editor, the values of the customs fields, which are invisible in the editor, get wiped out as the updated bug gets submitted to the repository. I believe that, until the time custom fields are supported in Jira, their values should be left alone.
We should probably make them non-editable fields.
I suppose the actual problem is no values are provided for the custom fields in the HTTP post so they are set to an empty value. A possible solution would be to use the SOAP interface or to provide correct values.
Is it possible to post the same values for custom fields/values that were originally retrieved? This is pretty much how Bugzilla works.
I think the values are never retrieved.
Ah. Do you know if it's possible to retrieve all custom values via ..mylar.jira.core?
I guess RssContentHandler would need to be updated and we'll need to extend org.eclipse.mylar.internal.jira.core.model to support custom fields too.
Looks like that custom fields are indeed part of the RSS feed: http://mylar.eclipse.org/jiratest/si/jira.issueviews:issue-xml/JIRATEST-3/JIRATEST-3.xml
They are and state machin in RssContentHandler already tracking those elements, but don't saving them into the model.
*** Bug 160781 has been marked as a duplicate of this bug. ***
Steffen: is this still happening? If so, would is there a fix on the JIRA SOAP end of things that would resolve it?
Yes, the bug is still there. The SOAP interface has support for custom fields but we currently use the web interface via POST requests to update bugs. We either need to switch the code to use SOAP or add custom field support to our RSS parser.
Steffen, do you have any ideas how we could test this? I have parser and some changes for update issue action, but want to add some tests before committing them. It also seems like I can show some of these attributes in the ui too (maybe hardcoding some of the stuff for now).
You could add custom fields to the test repository on mylar.eclipse.org.
Apparently JIRA could use custom fileds for indexing/searching needs. Those fields usually aren't shown in the ui but does appear in rss xml. I wonder if we need to preserve those fields when submitting update. Steffen, can you please drop "JIRA Toolkit" plugin to mylar.eclipse.org and restart tomcat server there? See instructions at http://confluence.atlassian.com/display/JIRAEXT/JIRA+Toolkit I believe Codehaus JIRA is using "participants" and "days since last commit" fields.
I installed http://repository.atlassian.com/jira-toolkit/jars/jira-toolkit-0.7.21.jar but the administrative interface of JIRA displays an error: Participants of an issue (participants) Displays reporter, current assignee and all commenters of the issue Error: There was a problem loading the descriptor for module 'customfield-type' in plugin 'JIRA Toolkit Plugin'. Error retrieving dependency of class: com.atlassian.jira.toolkit.customfield.ParticipantsCFType. Missing class: com/atlassian/jira/issue/customfields/impl/CalculatedCFType
Weird. I just tried it on local standalone jira install. Maybe there are some staged web app classes need to be cleaned somewhere in tomcat?
Sorry, I misread the install instructions. Should work now.
Thanks Steffen
Steffen, I committed first cut of custom fields support and added some basic test, though it seems like JiraTaskDataHandler is involved and it is not much covered by the tests. Can you try it out please? BTW, I wonder if JiraTaskDataHandler need to be updated to include attachment data, i.e. in buildJiraIssue() method (I moved it from JiraRepositoryConnector class since JiraTaskDataHandler is the only user of that method)
Created attachment 68504 [details] mylar/context/zip
That's great. I'll give it a shot tomorrow.
Note that I haven't added any support for editing or viewing those issues, just reading and persisting them. Perhaps we should use separate report for the editor support.
I've committed some UI nits for the editing custom attributes. Right now it is only on a best effort, so there are -- blank but editable attributes doesn't appear in the RSS data, and as result we can't show them -- blank and read-only attributes (not only custom ones) are filtered out, because it doesn't make sense to waste screen real estate on them -- because of JIRA api limitations, we only support custom attributes in the task editor, but not in the new custom task editor Anyways, doesn't seem like there is anything left here. Closing.
Created attachment 76374 [details] mylyn/context/zip
Good stuff. Are the current limitations clear enough in the FAQ?
(In reply to comment #25) > Good stuff. Are the current limitations clear enough in the FAQ? I've updated FAQ
