Community
Participate
Working Groups
The Bugzilla we are using is version 2.20 with some customization. We have added reproducibility, frequency, locales, work item type, Web request number fields to bugbase. Currently The Mylar Bugzilla plugin does not seem to support these fields. Is this something that we can add to our Mylar configuration or can we get a patch from you guy? We would really love to use the Mylar plug in but are stuck right now on a "legal reproducibility" error on a bug submit because of our bugzilla's custom fields.
This might require a custom connector that extends the current Bugzilla connector. We will investigate next week. Is there any other customization beyond what you have listed?
Thanks so much for the quick reply, we are excited to start using the Mylar plugin! ;-) No other customizations beyond that. Let me know if you need any other additional info from my end. Thanks again, -Kinra
Bugzilla 3.0 will have support for custom fields (http://www.bugzilla.org/releases/3.0/new-features.html#v30_feat_cf) We intend to support these custom fields in our rich editor. I would suggest migrating to Bugzilla 3.0 and Myalr 2.0 when available. On a technical note, currently the valid options for newly created custom fields are not being exported in the config rdf. I've brought this to their attention (https://bugzilla.mozilla.org/show_bug.cgi?id=287326#c40).
Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=374981
Does this mean that without having the filed Bugzilla-Bug fiex, it wont work in Mylar? We are currently migrating to Bugzilla 3.0 (RC1) and thinking abount using custom fields, so I am wondering if this Bug depends on the Bugzilla-Bug. Thx :=)
Correct. We need that Bugzilla bug fixed in order to support custom fields correctly in the rich editor.
Was not resolved in Bugzilla 3.0, deferring.
Tentatively scheduling for 2.1 since bugs.eclipse.org is likely to update to 3.0 in the same timeframe.
*** Bug 209131 has been marked as a duplicate of this bug. ***
The Bugzilla team has resolved the following bug: 374981: Custom field single select options not available in config.cgi rdf https://bugzilla.mozilla.org/show_bug.cgi?id=374981 We are now just waiting for next 3.0.x release that includes this fix.
3.0.3 was just release so we should be able to make progress on this now. Frank this is a high value item as can be seen by the number of votes. Do you want to take this on for 2.3? We'll need to be backwards compatible i.e disallow custom fields for Bugzilla < 3.0.3 and will need test coverage as per usual. I'll need to install a 3.0.3 test server (created bug#214835).
(In reply to comment #11) > 3.0.3 was just release so we should be able to make progress on this now. Frank > this is a high value item as can be seen by the number of votes. Do you want to > take this on for 2.3? We'll need to be backwards compatible i.e disallow custom > fields for Bugzilla < 3.0.3 and will need test coverage as per usual. I'll need > to install a 3.0.3 test server (created bug#214835). > Hi Rob, I will start with install the new 3.0.3 on my MacBook Pro when I come home.
Here some questions. 1) The rdf file contains all bugzilla fields an not only the custom fields. Should we store only the custom fields? 2) In the rdf file only name and desciption are included an not the other flags. Should we create a new bug for the missing fields? By example we did not know the type of the custom field (freetext, drop down). 3) I must extend the RepositoryConfiguration, which has a serialID. What is to do to get backward compatibility? Actual state of my work. new List for fields in RepositoryConfiguration (only the name of the fields) can be filled by the parser of the rdf file. Over the weekend I will continue the work.
1) For now it may be best to treat these as special and just store the additional custom fields 2) I haven't installed 3.0.3 yet here. Could you post or email me a copy of the rdf output from your 3.0.3 install so I can look at what we now get to work with? 3) Up the serial number and BugzillaCorePlugin will log the error, downloading a new config. I don't think we have any other option.
Created attachment 86762 [details] config.cgi of a clean 3.0.2 2) I haven't installed 3.0.3 yet here. Could you post or email me a copy of the rdf output from your 3.0.3 install so I can look at what we now get to work with?
Created attachment 86763 [details] config.cgi with one custom field No need for Bugzilla 3.0.3. You can do this with verson 3.0.2.
My understanding is that in 3.0.3 the option values for custom fields should now be in the rdf. I.e. when you define a single select field with options those options should now be available to us in the rdf. Is this the case?
Created attachment 86779 [details] proof of concept Questions: 1) Is it OK that I add a parameter to client.getTaskData. This is needed to have the RepositoryConfiguration within the SaxMultiBugReportContentHandler file. 2) Is it ther right way to show the custom Fieldes under the Attributes section in an extra area. Next steps Hope that I can finsh the cleanup until Wednesday.
Created attachment 86780 [details] mylyn/context/zip
This is looking good Frank, (In reply to comment #18) > 1) Is it OK that I add a parameter to client.getTaskData. This is needed to have > the RepositoryConfiguration within the SaxMultiBugReportContentHandler file. Since this is an internal class we have license to make these sort of changes, but I'm wondering if instead the client should be constructed with a configuration (if available), otherwise when getConfiguration is called it is set internal to BugzillaClient? That way the client has a configuration at its disposal. This would keep the api cleaner. Thoughts? > > 2) Is it ther right way to show the custom Fieldes under the Attributes section > in an extra area. That is fine for now and we can iterate on this if need be.
Great to see progress on this Frank!
(In reply to comment #20) > > Since this is an internal class we have license to make these sort of changes, > but I'm wondering if instead the client should be constructed with a > configuration (if available), otherwise when getConfiguration is called it is > set internal to BugzillaClient? That way the client has a configuration at its > disposal. This would keep the api cleaner. Thoughts? To read the Configuration from the cache file you need TaskRepository as an parameter. But in BugzillaClientFactory.createClient you only have ther repositoryURL. That wase the reason for add the customFields as an parameter for the two getTaskData methods of BugzillaClient. Or should we extend BugzillaCorePlugin.getRepositoryConfiguration(String repositoryUrl) to read the cache file like in BugzillaCorePlugin.getRepositoryConfiguration(TaskRepository repository, boolean forceRefresh).
(In reply to comment #22) > To read the Configuration from the cache file you need TaskRepository as an > parameter. But in BugzillaClientFactory.createClient you only have ther > repositoryURL. That wase the reason for add the customFields as an parameter for > the two getTaskData methods of BugzillaClient. One possible solution would be to set the cached configuration within the BugzillaClientManager.getClient() method right after client construction. We have a repository there. It will require an additional method on BugzillaClient for setting this value. This configuration could then get updated internally by the client whenever BugzillaClient.getRepositoryConfiguration() is called.
Created attachment 87200 [details] Patch Suggestion from comment 23 included
Created attachment 87201 [details] mylyn/context/zip
Created attachment 87302 [details] New Patch This patch use getManagedForm().getToolkit() instead of toolkit
Created attachment 87303 [details] mylyn/context/zip
Frank, is there code missing from SaxMultiBugReportContentHandler in this patch? I notice the custom fields are being passed in bug not used.
Also, are you able to cut a new patch that is synced with head? (If not possible I can resolve the conflicts).
(In reply to comment #28) > Frank, is there code missing from SaxMultiBugReportContentHandler in this patch? > I notice the custom fields are being passed in bug not used. (In reply to comment #29) > Also, are you able to cut a new patch that is synced with head? (If not possible > I can resolve the conflicts). Hope that I can look into before is start with my seminar(next two days).
Created attachment 90125 [details] correted patch Rob, I found a problem what is currently not solved. You must first update the repository Attributes to get the Custom Fields. I'm not at home for the next two days.
Created attachment 90126 [details] mylyn/context/zip
Frank, I'll defer this post 2.3 and help get this resolved early in the 3.0 cycle. My apologies for the lack of timely feedback on this.
I've set up a 3.0.3 at /bugs303 and added a custom field CF_FRUIT with APPLE and ORANGE as the possible values. Upon trying to create a new bug report and opening I'm getting the following exception. Frank, if you could investigate these add some test coverage now that we have a 3.0.3 server that would be great. I'll post and updated patch... java.lang.IllegalArgumentException: No enum const class org.eclipse.mylyn.internal.bugzilla.core.BugzillaReportElement.CF_FRUIT at java.lang.Enum.valueOf(Unknown Source) at org.eclipse.mylyn.internal.bugzilla.core.BugzillaReportElement.valueOf(BugzillaReportElement.java:1) at org.eclipse.mylyn.internal.bugzilla.core.BugzillaTaskDataHandler.updateAttributeOptions(BugzillaTaskDataHandler.java:497) at org.eclipse.mylyn.internal.bugzilla.core.BugzillaTaskDataHandler.configureTaskData(BugzillaTaskDataHandler.java:187) at org.eclipse.mylyn.internal.bugzilla.core.BugzillaTaskDataHandler.getTaskData(BugzillaTaskDataHandler.java:92) at org.eclipse.mylyn.tasks.core.AbstractRepositoryConnector.createTaskFromExistingId(AbstractRepositoryConnector.java:102) at org.eclipse.mylyn.tasks.core.AbstractRepositoryConnector.createTaskFromExistingId(AbstractRepositoryConnector.java:91) at org.eclipse.mylyn.tasks.ui.editors.AbstractRepositoryTaskEditor.updateSubmittedTask(AbstractRepositoryTaskEditor.java:3796) at org.eclipse.mylyn.tasks.ui.editors.AbstractNewRepositoryTaskEditor.updateSubmittedTask(AbstractNewRepositoryTaskEditor.java:476) at org.eclipse.mylyn.tasks.ui.editors.AbstractRepositoryTaskEditor$49.run(AbstractRepositoryTaskEditor.java:3560) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Created attachment 94017 [details] Updated patch, minor alterations
Created attachment 94073 [details] updated patch with jUnit Test Correction for failure of comment 34 and usage of the new Test Bugzilla (3.0.3). Rob, hope that this was what you expect.
Created attachment 94074 [details] mylyn/context/zip
Looking good Frank! I've added a second custom field "cf_testfield2" to bugs303 that is of type fee text. Unfortunately it looks like this field isn't appearing in the the task xml sent by bugzilla when the field is blank, which results in this field not being visible in the editor. To circumvent this we'll probably need to create all custom fields (in the task xml or not) in the editor. If the custom attribute has no options we render it as a free text field in the editor. Thoughts? Additionally, it would be cool if we could add custom attribute support to the NewBugzillaTaskEditor, but we don't have access to the "Can be set on bug creation" field in the config rdf output. We'll need to investigate whether the new bugzilla web service api is exposing this field or not (perhaps as part of bug#154785 ). Once we know this we can decide how to proceed (submit bug report or defer until we adopt the ws api).
(In reply to comment #38) > Looking good Frank! I've added a second custom field "cf_testfield2" to bugs303 > that is of type fee text. Unfortunately it looks like this field isn't > appearing in the the task xml sent by bugzilla when the field is blank, which > results in this field not being visible in the editor. To circumvent this we'll > probably need to create all custom fields (in the task xml or not) in the > editor. Actually in BugzillaTaskEditor.createCustomAttributeLayout we iterate over all CustomFields from the Configuration. Is your configuration up to date (did you an update Attributes after definition of testfield2) > If the custom attribute has no options we render it as a free text field > in the editor. Thoughts? > > Additionally, it would be cool if we could add custom attribute support to the > NewBugzillaTaskEditor, but we don't have access to the "Can be set on bug > creation" field in the config rdf output. Should we report this as an enhancment request to Bugzilla? > We'll need to investigate whether the > new bugzilla web service api is exposing this field or not (perhaps as part of > bug#154785 ). Once we know this we can decide how to proceed (submit bug report > or defer until we adopt the ws api). I take a look for this!
(In reply to comment #39) > (In reply to comment #38) > > We'll need to investigate whether the > > new bugzilla web service api is exposing this field or not (perhaps as part of > > bug#154785 ). Once we know this we can decide how to proceed (submit bug report > > or defer until we adopt the ws api). > I take a look for this! This can take some time becaus on my bugzilla I have some problem with bz_webservice_demo.pl.
Patch applied and ip log updated. (In reply to comment #39) > Actually in BugzillaTaskEditor.createCustomAttributeLayout we iterate over > all CustomFields from the Configuration. Is your configuration up to date (did > you an update Attributes after definition of testfield2) This was likely the problem. I've committed your patch. There was some problems merging BugzillaRepositoryConnector so if you don't mind, could you do a sanity check between that class and your copy and provide an updated patch for BugzillaRepositoryConnector if necessar? > > We'll need to investigate whether the > > new bugzilla web service api is exposing this field or not (perhaps as part of > > bug#154785 ). Once we know this we can decide how to proceed (submit bug > report > > or defer until we adopt the ws api). > I take a look for this! Great. No rush here Frank. In terms of the layout of custom fields, we may want to consider just appending them to the regular attributes section, just before the depends on field rather than giving these an entirely separate section. Frank, Mik, what are your thoughts on this?
Created attachment 95839 [details] new Implementation (comment 41) (In reply to comment #41) > In terms of the layout of custom fields, we may want to consider just appending > them to the regular attributes section, just before the depends on field rather > than giving these an entirely separate section. Frank, Mik, what are your > thoughts on this? Rob, I think we should move the attribute up (as you suggested) but then we should remove the separator line. This is included in the patch.
Created attachment 95840 [details] mylyn/context/zip
Perfect. Patch applied, ip log updated. Created bug#226851 to address the new bug editor.
(In reply to comment #38) > Additionally, it would be cool if we could add custom attribute support to the > NewBugzillaTaskEditor, but we don't have access to the "Can be set on bug > creation" field in the config rdf output. We'll need to investigate whether the > new bugzilla web service api is exposing this field or not (perhaps as part of > bug#154785 ). Once we know this we can decide how to proceed (submit bug > report or defer until we adopt the ws api). Sorry the bug spam. I see this bug is fixed, and indeed bugzilla custom fields are supported in the task editor. Unfortunately in the "new task" editor there are no custom fields listed. Are there any plans of adding support to custom fields in the new task editor? I've read bug #154785 which is still open and looks stalled for more then two years. What is the status with Mylyn support for custom fields in the new task editor, and what can be done to get this complete?
Consider adding yourself to the cc on bug#279357 as Frank has begun to address this need.
