Community
Participate
Working Groups
Bugzilla 3.2 allows the administrator to customize the status workflow sequence (http://mylyn.eclipse.org/bugs32/editworkflow.cgi).
(In reply to comment #0) > Bugzilla 3.2 allows the administrator to customize the status workflow sequence > (http://mylyn.eclipse.org/bugs32/editworkflow.cgi). Rob, right now there's no way for WebService or other clients to have any idea what a valid status transition so we must wait until https://bugzilla.mozilla.org/show_bug.cgi?id=449143 is solved.
(In reply to comment #1) > (In reply to comment #0) > > Bugzilla 3.2 allows the administrator to customize the status workflow > sequence > > (http://mylyn.eclipse.org/bugs32/editworkflow.cgi). > > Rob, > > right now there's no way for WebService or other clients to have any idea what a > valid status transition so we must wait until > https://bugzilla.mozilla.org/show_bug.cgi?id=449143 is solved. Rob, we can do this if we have https://bugzilla.mozilla.org/show_bug.cgi?id=504937 solved.
*** Bug 279476 has been marked as a duplicate of this bug. ***
*** Bug 295294 has been marked as a duplicate of this bug. ***
*** Bug 302844 has been marked as a duplicate of this bug. ***
While we are waiting for https://bugzilla.mozilla.org/show_bug.cgi?id=449143 , would it be possible to add some capability in Mylyn to read a user-selected configuration file that specifies custom workflows? I've heard that several groups are already trying to create and maintain different versions of Mylyn just so it is compatible with their custom workflows, and I myself have done this for Red Hat. This may be a good first step toward unifying those different versions of Mylyn, and the code may mostly be reusable when the aforementioned Bugzilla bug is fixed. I'd be happy to work on this, if Mylyn has any interest. The proposal: Parse a user-specified file, determine what custom workflows are enabled. Associate one such file with each repository (optional, so users can choose not to have one if they wish).
Sounds great Charley. These files could reside in the plugin state location - Platform.getStateLocation(BugzillaCorePlugin.getDefault().getBundle()). Could you post a proposed file format? Thanks.
(In reply to comment #7) > Sounds great Charley. These files could reside in the plugin state location - > Platform.getStateLocation(BugzillaCorePlugin.getDefault().getBundle()). Could > you post a proposed file format? Thanks. Sure! Also, it appears https://bugzilla.mozilla.org/show_bug.cgi?id=449143 has been fixed, though at present it looks like it will be in Bugzilla 3.6. I don't know about any plans for backporting, but I'll hold off on a file format until I get a better grasp of how the new API/config.cgi will work and what format it uses to return valid transitions.
Created attachment 163948 [details] Fetch from Bug.fields Checked the output of bug.fields from Bug.fields in Bugzilla 3.6, will proceed with this bug using this as a guide to formatting. Attached scriptlet used to check the output. Usage: `python xml.py`
Created attachment 163951 [details] output of Bug.fields from Bugzilla 3.6 rc1 Bugzilla version: {'version': '3.6rc1+'} So I will try to get Mylyn to parse a Bugzilla descriptor file that stores: can_change_to: [NEW,ASSIGNED,RESOLVED], name: UNCONFIRMED can_change_to: [ASSIGNED,RESOLVED], name: NEW etc. etc. Mylyn should be capable of handling the name-value pairs properly when connecting to a Bugzilla with this fields method.
(In reply to comment #10) > Created an attachment (id=163951) [details] > output of Bug.fields from Bugzilla 3.6 rc1 > > Bugzilla version: > {'version': '3.6rc1+'} > > So I will try to get Mylyn to parse a Bugzilla descriptor file that stores: > > can_change_to: [NEW,ASSIGNED,RESOLVED], name: UNCONFIRMED > can_change_to: [ASSIGNED,RESOLVED], name: NEW > etc. etc. > > Mylyn should be capable of handling the name-value pairs properly when > connecting to a Bugzilla with this fields method. On a side note, just to be clear, the Bug.fields method is currently only available on Bugzilla 3.6. The sample output attached comes from printing the result of an xmlrpc query as a string in Python.
Sounds good Charley, note that Frank Becker (cc'd) is putting the finishing touches on the xmlrpc client for extracting this information from Bugzilla 3.6 so if the two of you could coordinate to ensure this works under 3.6 and falls back to the config file for < 3.6 that would be great.
(In reply to comment #12) > Sounds good Charley, note that Frank Becker (cc'd) is putting the finishing > touches on the xmlrpc client for extracting this information from Bugzilla 3.6 > so if the two of you could coordinate to ensure this works under 3.6 and falls > back to the config file for < 3.6 that would be great. Putting finishing touches on a patch against Mylyn head that covers basic workflow customization from a descriptor file. Trying to run eclipse.mylyn.tests.AllTests to make sure I haven't broken anything else, as per the guidelines. Here is the design proposal: http://wiki.eclipse.org/User_talk:Charley.wang.gmail.com Comments/criticism welcome :) The patch I'm working on testing covers Customization Case #1. Would it be better to submit the patches for each customization case, or to do all cases in one patch? -Charley
(In reply to comment #13) > (In reply to comment #12) > > Sounds good Charley, note that Frank Becker (cc'd) is putting the finishing > > touches on the xmlrpc client for extracting this information from Bugzilla 3.6 > > so if the two of you could coordinate to ensure this works under 3.6 and falls > > back to the config file for < 3.6 that would be great. > > Putting finishing touches on a patch against Mylyn head that covers basic > workflow customization from a descriptor file. Trying to run > eclipse.mylyn.tests.AllTests to make sure I haven't broken anything else, as per > the guidelines. > > Here is the design proposal: > http://wiki.eclipse.org/User_talk:Charley.wang.gmail.com > > Comments/criticism welcome :) If we create a IBugzillaOperation we should look if we can remove the enum and create an abstract class. The enum is only used in RepositoryConfiguration.addOperation Method. Thougths? > > The patch I'm working on testing covers Customization Case #1. Would it be > better to submit the patches for each customization case, or to do all cases in > one patch? I think that it is better to have a patch per customization case. Then it is easer to review and maybe in the other case we have a big patch that needs a CQ. > > -Charley
Created attachment 165965 [details] mylyn/context/zip
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Sounds good Charley, note that Frank Becker (cc'd) is putting the finishing > > > touches on the xmlrpc client for extracting this information from Bugzilla 3.6 > > > so if the two of you could coordinate to ensure this works under 3.6 and falls > > > back to the config file for < 3.6 that would be great. > > > > Putting finishing touches on a patch against Mylyn head that covers basic > > workflow customization from a descriptor file. Trying to run > > eclipse.mylyn.tests.AllTests to make sure I haven't broken anything else, as per > > the guidelines. > > > > Here is the design proposal: > > http://wiki.eclipse.org/User_talk:Charley.wang.gmail.com > > > > Comments/criticism welcome :) > If we create a IBugzillaOperation we should look if we can remove the enum and > create an abstract class. > The enum is only used in RepositoryConfiguration.addOperation Method. > > Thougths? This would be great if Mylyn is okay with it! I wasn't sure if you would accept a fundamental change to the BugzillaOperation class. I will get rid of the enum and replace with an abstract class. > > I think that it is better to have a patch per customization case. Then it is > easer to review and maybe in the other case we have a big patch that needs a > CQ. Sure! I'll try to get some unit tests going and add the filename option to the preferences box. Quick question: Is a default filename necessary? If the option is in the preference box for the repository, I am leaning towards no. Especially since there isn't much in RepositoryConfiguration I can use to create a default filename (except the URL, which I am currently using) -Charley > > > > > -Charley
(In reply to comment #16) > (In reply to comment #14) ... > > Quick question: Is a default filename necessary? If the option is in the > preference box for the repository, I am leaning towards no. Especially since > there isn't much in RepositoryConfiguration I can use to create a default > filename (except the URL, which I am currently using) Sorry for the late reply! I think that should use org.eclipse.mylyn.tasks.core.TaskRepository.setProperty(String, String) and org.eclipse.mylyn.tasks.core.TaskRepository.getProperty(String) there. > > -Charley
(In reply to comment #17) > > Sorry for the late reply! > > I think that should use > org.eclipse.mylyn.tasks.core.TaskRepository.setProperty(String, String) and > org.eclipse.mylyn.tasks.core.TaskRepository.getProperty(String) there. Thanks! On a related note, I'm trying to configure a local Bugzilla install to test custom transitions with. I fixed JUnit test errors in the AllBugzillaHeadlessStandaloneTests, but I'm getting a number of errors in AllBugzillaTests, many of which are related to the settings (or lack thereof) on my Bugzilla. I'm trying to copy existing installations set up for Mylyn testing, but there are a lot of settings -- does Mylyn have an established way to clone and set up new test installations? I don't see mention of it in the Contributor's Guide. -Charley
(In reply to comment #18) > (In reply to comment #17) > > > > Sorry for the late reply! > > > > I think that should use > > org.eclipse.mylyn.tasks.core.TaskRepository.setProperty(String, String) and > > org.eclipse.mylyn.tasks.core.TaskRepository.getProperty(String) there. > > > Thanks! > > On a related note, I'm trying to configure a local Bugzilla install to test > custom transitions with. I fixed JUnit test errors in the > AllBugzillaHeadlessStandaloneTests, but I'm getting a number of errors in > AllBugzillaTests, many of which are related to the settings (or lack thereof) > on my Bugzilla. I'm trying to copy existing installations set up for Mylyn > testing, but there are a lot of settings -- does Mylyn have an established way > to clone and set up new test installations? I don't see mention of it in the > Contributor's Guide. > > -Charley We have an test repository at http://mylyn.eclipse.org/bugs36/ and I can add some custom status values and change the transitions. Plese tell me what you need.
Created attachment 166203 [details] status_settings (In reply to comment #19) > We have an test repository at http://mylyn.eclipse.org/bugs36/ and I can add > some custom status values and change the transitions. Plese tell me what you > need. That would be great! These are the custom transitions settings I am presently using for case 1: Test adding new transitions: NEW --> CLOSED Test removing transitions: REOPENED -/-> NEW Test removing all transitions (except RESOLVED): CLOSED Test enable all transitions: REOPENED I've attached a quick screenshot of what my custom workflows table looks like in Bugzilla. Also, I tried to run tests on the bugs36 installation, got a test failure in BugzillaCustomFieldsTest -- it looks like the cf_multiselect attribute didn't have a value set for bug 1. I set the value in Bug 1 to Green so the test would pass, please let me know if it should be reset to null :) -Charley
Created attachment 166211 [details] Status settings Ack, I think I did a printscreen of the wrong local Bugzilla installation. Here's a corrected screenshot, and I believe these are the changes from the default workflow settings: Test adding new transitions: NEW --> CLOSED Test removing transitions: ASSIGNED -/-> NEW Test removing all transitions (except RESOLVED): CLOSED Test enable all transitions: REOPENED
(In reply to comment #21) > Created an attachment (id=166211) > Status settings > > Ack, I think I did a printscreen of the wrong local Bugzilla installation. > Here's a corrected screenshot, and I believe these are the changes from the > default workflow settings: > > Test adding new transitions: > NEW --> CLOSED > > Test removing transitions: > ASSIGNED -/-> NEW > > Test removing all transitions (except RESOLVED): > CLOSED > > Test enable all transitions: > REOPENED For now please use http://mylyn.eclipse.org/bugs36customWF/. We must discuss if it is OK to set up three repositories for version 3.6.
So I got most of the Bugzilla tests working. However the bugs36customWF seems to be missing some of the customizations? I performed workflow tests using my local Bugzilla installation. Is there any way I could get admin access to bugs36customWF to change the workflows there? I would of course thoroughly document everything I change :) I'm going to look into corner cases (e.g. transitions to CLOSED require a resolution status) and improving the workflow which is currently a bit cumbersome Is there a good place to check/parse a descriptor file? I currently have it in RepositoryConfiguration.addValidOperations, parsing file specified by user in the repository's properties page. This forces some hand-waving to avoid parsing the descriptor file every time addValidOperations is called. I'll upload the current patch after some cleanup. -Charley PS: If you would ever like to discuss in real-time, I am charley on IRC freenode, usually in #eclipse.
(In reply to comment #23) > So I got most of the Bugzilla tests working. However the bugs36customWF seems > to be missing some of the customizations? I performed workflow tests using my > local Bugzilla installation. Is there any way I could get admin access to > bugs36customWF to change the workflows there? I would of course thoroughly > document everything I change :) I did some corrections. Please tell me of something is still not there I must talk to Rob if it is possible to give you admin right, but this is next week. > > I'm going to look into corner cases (e.g. transitions to CLOSED require a > resolution status) and improving the workflow which is currently a bit > cumbersome > > Is there a good place to check/parse a descriptor file? I currently have it in > RepositoryConfiguration.addValidOperations, parsing file specified by user in > the repository's properties page. This forces some hand-waving to avoid parsing > the descriptor file every time addValidOperations is called. I think the right place is BugzillaClient.getRepositoryConfiguration > > I'll upload the current patch after some cleanup. > > -Charley > > PS: If you would ever like to discuss in real-time, I am charley on IRC > freenode, usually in #eclipse. Sorry actually I did not have setup an IRC Client on my MacBook Pro.
> > So I got most of the Bugzilla tests working. However the bugs36customWF seems > > to be missing some of the customizations? I performed workflow tests using my > > local Bugzilla installation. Is there any way I could get admin access to > > bugs36customWF to change the workflows there? I would of course thoroughly > > document everything I change :) > > I did some corrections. Please tell me of something is still not there > I must talk to Rob if it is possible to give you admin right, but this is next > week. Unfortunately that will not be possible. We need to restrict administrative access to Eclipse.org infrastructure to Mylyn committers. Charley, can you describe the changes you need or provide a configuration file that we could put in place?
Created attachment 166511 [details] mylyn/context/zip Context for patch
Created attachment 166531 [details] patch v 1.0 Here's a patch. There are some things I'd like to change, but the functionality is working. Parses file selected in the properties page of a repository, sets a custom workflow. Custom workflow changes the operations visible when a task is opened. If the CLOSED status is available to an un-RESOLVED bug, the resolution status box appears beside it. This is necessary because Bugzilla requires a resolution for CLOSED bugs. I tried to follow the submission guidelines set out in the contributor guide, please let me know if anything is wrong and I'd be happy to fix it up. (JUnit tests) Ran AllBugzillaTests. It looks like bugs36customWF is set up right now, thank you! I currently have test failures, though they all appear unrelated to what I have done. (4x failures) testRDFProductConfig (x2, bugs36customWF) testxmlrpcInstalled (x1, bugs36customWF) testCustomAttributes (x1, bugs32) (2x errors) testxmlrpc (x1, bugs37) testxmlrpcInstalled (x1, bugs37) (Want to change) - Make descriptor file text box untypeable, open file dialog box whenever the text box is selected - Add 'Refresh descriptor file' to repository's right-click menu - Set up a class to manage all valid transitions. Assign a property to each TaskRepository to let it find its corresponding descriptor file. - Suggestions?
Created attachment 166532 [details] mylyn/context/zip
Created attachment 167379 [details] updated patch v 1.0 Charley, sorry for take so long to come to this. I did a review and have some points. 1) please add an open button with a FileOpen Dialog in the BugzillaRepositorySettingsPage.createAdditionalControls to set the text of descriptorFile 2) In BugzillaClient.getPairsForExisting we have some transformations for BugzillaOperation depending of the version. Do you think it is possible to extend CustomTransitionManager to support this? 3) Should we add an operation for setting the CustomTransitionManager from the XMLRPC result or should we add operations for set the values? I only do some small changes (corrections for custom-wf url) Thougths?
Created attachment 167380 [details] mylyn/context/zip
Created attachment 167481 [details] Patch for this bug (In reply to comment #29) > Created an attachment (id=167379) [details] > updated patch v 1.0 > > Charley, > > sorry for take so long to come to this. No worries :) > > I did a review and have some points. > > 1) please add an open button with a FileOpen Dialog in the > BugzillaRepositorySettingsPage.createAdditionalControls > to set the text of descriptorFile Sure. I've done this in the new patch. Also left some commented code to browse without using a button (open File Dialog and disable the text box when the user clicks into the descriptorFile). > > 2) In BugzillaClient.getPairsForExisting we have some transformations for > BugzillaOperation depending of the version. Do you think it is possible to > extend CustomTransitionManager to support this? Sure -- I was going to do this by adding verifier objects to custom bugzilla operations, though the only version restrictions I've seen have been for Bugzilla < 3.2 and custom workflows are only valid for Bugzilla >= 3.2. > > 3) Should we add an operation for setting the CustomTransitionManager from the > XMLRPC result or should we add operations for set the values? I was going to use XMLRPC to populate the CustomTransitionManager if no descriptor file is present. There are some workflow-related customizations I can't find in XMLRPC. Do you know if it's possible to get the end-state of a Duplicate action? Bugzilla allows duplicate bugs to be set to RESOLVED, CLOSED or VERIFIED. Mylyn support for this customization is included in the current patch by grabbing the duplicate status from RepositoryConfiguration in BugzillaClient.getPairsForExisting. Would setting it as a mapped attribute be better? > > I only do some small changes (corrections for custom-wf url) Sure! I currently can't seem to access the bugzilla repository with the new url? I ran the tests again using the old custom Bugzilla URL, the only test failures I get are for RDFProductConfig, and one failure + 2 errors for xmlrpc on 3.7 and 3.6-custom. -Charley
Created attachment 167482 [details] mylyn/context/zip
Created attachment 167810 [details] updated May-7-patch-mylyn I changed BugzillaRepositoryPage to add an ModifyListener for verify the descriptorFile. The UI is changed to show the descriptorFile with a minimal size the changes when you resize the window. Please verify!
Created attachment 167811 [details] mylyn/context/zip
Charley, we need an QC for this patch. Can you please include the other custom cases so we only need one QC.
Created attachment 168149 [details] Patch including custom status names Custom status names enabled. I'm doing some manual testing with a more heavily customized local Bugzilla installation. I will modify this installation and the JUnit tests to cover all customization scenarios. For automated testing, would a mysqldump of my local bugs database be useful?
Created attachment 168150 [details] mylyn/context/zip
(In reply to comment #36) > Created an attachment (id=168149) [details] > Patch including custom status names > > Custom status names enabled. I'm doing some manual testing with a more heavily > customized local Bugzilla installation. I will modify this installation and the > JUnit tests to cover all customization scenarios. > > For automated testing, would a mysqldump of my local bugs database be useful? I think that Status Settings like in attachment (id=166211) for ../editworkflow.cgi and /editworkflow.cgi?action=edit_comment is OK if you can give my the following information for the new status values. I need Statusname, sortkey and statustyp (open/close)
Created attachment 168268 [details] Screenshot Sure. To make it easier, I've stripped the cases down to the bare minimum required for the custom workflow tests to run. You can quickly get this set up by emptying the status_workflow table in mysql and checking the few remaining boxes in editworkflow.cgi. Stripping away unused transitions also makes it easier to tell at a glance what is being tested. I added 3 statuses: insert into bug_status values (8, "ON_DEV", 800, 1, NULL, 1); insert into bug_status values (9, "POST", 900, 1, NULL, 0); insert into bug_status values (12, "MODIFIED", 1200, 1, NULL, 1); The automated tests touch each customization case. Let me know if you need more workflow transitions for test coverage and I can add them back. The only test errors/failures I am currently getting on my local installation are related to missing flags/xmlrpc.
(In reply to comment #39) > Created an attachment (id=168268) > Screenshot > > Sure. > > To make it easier, I've stripped the cases down to the bare minimum required for > the custom workflow tests to run. You can quickly get this set up by emptying > the status_workflow table in mysql and checking the few remaining boxes in > editworkflow.cgi. Stripping away unused transitions also makes it easier to tell > at a glance what is being tested. > > I added 3 statuses: > insert into bug_status values (8, "ON_DEV", 800, 1, NULL, 1); > insert into bug_status values (9, "POST", 900, 1, NULL, 0); > insert into bug_status values (12, "MODIFIED", 1200, 1, NULL, 1); Hope that I can setup the new repository today. > > The automated tests touch each customization case. Let me know if you need more > workflow transitions for test coverage and I can add them back. I will check this with your next patch after we have the new repository > > The only test errors/failures I am currently getting on my local installation > are related to missing flags/xmlrpc. I will check this with your next patch after we have the new repository Please change BugzillaClient.postTaskData and getTaskData to not always call repositoryConfiguration.setValidTransitions and add in BugzillaRepositorySetting.applyTo that if the filename is not the same we update the Transitions.
Created attachment 168420 [details] Patch with new fixes I've made the fix. I left the call to setValidTransitions in the BugzillaRepositoryConnector to cover the case when repositoryConfiguration is null in BugzillaRepositorySetting.applyTo, which is the case when a repository has never been connected to. I ran tests before/after patch application using my local installation and there don't seem to be any differences in the pertinent bugs, though I seem to be getting a lot of test failures before and after patch application. A
Created attachment 168421 [details] Patch with new fixes I've made the fix. I left the call to setValidTransitions in the BugzillaRepositoryConnector to cover the case when repositoryConfiguration is null in BugzillaRepositorySetting.applyTo, which is the case when a repository has never been connected to. I ran tests before/after patch application using my local installation and there don't seem to be any differences in the pertinent bugs, though I seem to be getting a lot of test failures before and after patch application. Are there any nightly builds for Mylyn that I can consult to cross-check test results? Thanks!
Created attachment 168422 [details] mylyn/context/zip
Created attachment 168442 [details] transformation table This is the new repository http://mylyn.eclipse.org/bugs36-custom-wf-and-status/editworkflow.cgi the jpeg show the actual transformation table. Please let me know if this is OK for you. You can write junit Test using BugzillaFixture.BUGS_3_6_CUSTOM_WF_AND_STATUS
(In reply to comment #44) > Created an attachment (id=168442) [details] > transformation table > > This is the new repository > http://mylyn.eclipse.org/bugs36-custom-wf-and-status/editworkflow.cgi > > the jpeg show the actual transformation table. > > Please let me know if this is OK for you. > > You can write junit Test using BugzillaFixture.BUGS_3_6_CUSTOM_WF_AND_STATUS Sorry for not being clear -- in order to test Customization Case 2 I set the Bugzilla duplicate status to be CLOSED instead of RESOLVED. [I tried to cover all the cases in one Bugzilla installation to reduce the number of installations that need to be maintained]. Otherwise there should be no problems, I will reconfigure and re-run the tests for before/after. -Charley
(In reply to comment #45) > Otherwise there should be no > problems, I will reconfigure and re-run the tests for before/after. Quick note that the custom workflow test does break down on bugs-36-custom-wf-and-status. The custom workflow test uses a descriptor file that sets the Duplicate Status to CLOSED instead of RESOLVED. It's because the automated test assumes all 3 customization cases were applied to the same Bugzilla installation. It reduces the number of installations that have to be maintained and tested, if you feel it does not offer sufficient test coverage I can split the customization cases over 2 Bugzilla installations and write additional tests. Currently only the one installation specified in https://bugs.eclipse.org/bugs/attachment.cgi?id=168268 is necessary for the tests to function. In the patches, I set TEST_BUGZILLA_36_CUSTOM_URL = getServerUrl("bugs36-custom-wf-and-status") and used that to test. Thanks! > > -Charley
Created attachment 168473 [details] updated patch (attachment id=168421) I include some code to set the BUGZILLA_DESCRIPTOR_FILE property in the BugzillaFixture if the file exists in the testdata folder. (In reply to comment #45) > (In reply to comment #44) > Sorry for not being clear -- in order to test Customization Case 2 I set the > Bugzilla duplicate status to be CLOSED instead of RESOLVED. [I tried to cover > all the cases in one Bugzilla installation to reduce the number of > installations that need to be maintained]. Otherwise there should be no > problems, I will reconfigure and re-run the tests for before/after. > > -Charley the BUGS_3_6_CUSTOM_WF_AND_STATUS repostory is changed. (In reply to comment #42) > > Are there any nightly builds for Mylyn that I can consult to cross-check test > results? > > Thanks! Sorry because we need an QC it is not possible to include your code in an weekly build.
Created attachment 168474 [details] mylyn/context/zip
Created attachment 168603 [details] Patch Thanks for the quick reply. The tests didn't appear to run fully from the most recent patch. I disabled the transition file for ordinary unmodified Bugzilla 3.6 and other minor changes to the tests. Because the customization cases are covered in bugs36-custom-wf-and-status, bugs36-custom-wf isn't really necessary, unless you would like me to expand test coverage. Please let me know if there's anything else that I need to do. I will start writing some functions to fetch customization information from your xmlrpc classes. Also, just so you know, I'll be away for 2 weeks starting next week, I'll have Bugzilla access through my phone but not regular access to a computer.
Created attachment 168604 [details] mylyn/context/zip
(In reply to comment #49) > Created an attachment (id=168603) [details] > Patch > > Thanks for the quick reply. > > The tests didn't appear to run fully from the most recent patch. I disabled the > transition file for ordinary unmodified Bugzilla 3.6 and other minor changes to > the tests. > > Because the customization cases are covered in bugs36-custom-wf-and-status, > bugs36-custom-wf isn't really necessary, unless you would like me to expand > test coverage. > > Please let me know if there's anything else that I need to do. It I hav your latest patch I try to do the QC in this time, but I think you need to answer some questions to finish the QC. Please see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf for the needed steps. I create bug#311966: create XMLRPC operation for status transition (https://bugs.eclipse.org/bugs/show_bug.cgi?id=311966) for the xplrpc part. I need CustomTransitionManager so that I can add an method to parse the xmlrpc result and reuse your implementation. > > I will start writing some functions to fetch customization information from > your xmlrpc classes. Also, just so you know, I'll be away for 2 weeks starting > next week, I'll have Bugzilla access through my phone but not regular access to > a computer.
(In reply to comment #51) > It I hav your latest patch I try to do the QC in this time, but I think you > need to answer some questions to finish the QC. > Please see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf for the > needed steps. > > I create bug#311966: create XMLRPC operation for status transition > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=311966) for the xplrpc part. > > I need CustomTransitionManager so that I can add an method to parse the xmlrpc > result and reuse your implementation. The latest attached patch (2010-05-14 16:14 EDT, Charley Wang) is the final one. I've started on a method to parse the xmlrpc result, I'll finish it up and post it this weekend if a patch has not already been attached to 311966. If the XMLrpc and CustomTransitionManager are already checked in the additional function should be <250 lines. As for the CQ, I don't think I can create one myself for Mylyn, I believe only committers can create the initial CQ? I can answer the questions -- see below. Name: Bugzilla Custom Workflow support Description: Provides support for Custom Bugzilla workflows, including changing status transitions, changing status names and special settings for Duplicate Status and new closed bug statuses. Support is provided through a standardized descriptor file, though there are plans to add xmlrpc support later on. Reason: Since Bugzilla 3.4, custom workflows have been possible in Bugzilla installations. Mylyn currently does not support the full range of customizations available to Bugzilla, this patch aims to move Mylyn toward full support. Bug number: 259291 Cryptography: No. Author(s): Charley Wang Thanks, -Charley
I add the CQ#4117. Steffen, Rob, can you please look if all needed stuff is there.
Created attachment 168653 [details] Patch 1.1 Revised error handling in the parsing of the descriptor file. Will throw an IOException with message about what caused the exception, and it will also terminate earlier when the descriptor file is invalid. I will update the CQ patch tomorrow to this version if there are no objections.
Created attachment 168654 [details] mylyn/context/zip
*** Bug 315104 has been marked as a duplicate of this bug. ***
(In reply to comment #56) > *** Bug 315104 has been marked as a duplicate of this bug. *** The CQ appears to have passed -- will the patch be applied to upstream? I need to make a modification for 315104. Bugzilla behaviour is a little tricky to emulate for new bugs. For most installations, Mylyn needs to know if a user's 'canconfirm' flag is set before it can determine whether to set a bug as NEW or UNCONFIRMED. This flag does not appear to be visible. An easy default behaviour that should catch most installations would be: If any start-status other than UNCONFIRMED is available, use that status. Use the first one if there are multiple. Else use UNCONFIRMED. Information on which statuses are available can be obtained through xmlrpc or a descriptor file, like in this patch. -C
(In reply to comment #57) > (In reply to comment #56) > > *** Bug 315104 has been marked as a duplicate of this bug. *** > > The CQ appears to have passed -- will the patch be applied to upstream? > > I need to make a modification for 315104. Bugzilla behaviour is a little tricky > to emulate for new bugs. For most installations, Mylyn needs to know if a > user's 'canconfirm' flag is set before it can determine whether to set a bug as > NEW or UNCONFIRMED. This flag does not appear to be visible. > > An easy default behaviour that should catch most installations would be: > > If any start-status other than UNCONFIRMED is available, use that status. Use > the first one if there are multiple. > Else use UNCONFIRMED. > > Information on which statuses are available can be obtained through xmlrpc or a > descriptor file, like in this patch. > > -C Sorry, we have to wait until 3.4 is released !
Created attachment 172455 [details] commited patch Charley, here we go.
Created attachment 172456 [details] mylyn/context/zip
Thanks Frank. I have added copyright notices and @author tags where appropriate. What's left to do here?
(In reply to comment #61) > Thanks Frank. I have added copyright notices and @author tags where appropriate. Thanks for fixing this. > What's left to do here? Charley will do some code for fix "Problem with custom initial state for Bugzilla" (bug# 315104) see comment#57
> Charley will do some code for fix "Problem with custom initial state for > Bugzilla" (bug# 315104) see comment#57 Good. Charley, can you create a new task for that? It's easier to manage one contribution per task since we haven't converted to the automatic IP log, yet. I have also removed the IP log flag set on the bug. We need to set those on the patch attachments otherwise the entire comment stream is considered a contribution.
(In reply to comment #63) > > Charley will do some code for fix "Problem with custom initial state for > > Bugzilla" (bug# 315104) see comment#57 > > Good. Charley, can you create a new task for that? It's easier to manage one > contribution per task since we haven't converted to the automatic IP log, yet. > > I have also removed the IP log flag set on the bug. We need to set those on the > patch attachments otherwise the entire comment stream is considered a > contribution. Sure -- please see bug# 317729. Thanks! I'll also be taking a look at bug# 311966 to enable these operations with xmlrpc as well as the transitions file.
Thanks for putting in this effort Charley! Is the format of the file that specifies the workflow transitions documented anywhere? Frank, please free to close this bug if we are all done here.
(In reply to comment #65) > Thanks for putting in this effort Charley! Is the format of the file that > specifies the workflow transitions documented anywhere? > > Frank, please free to close this bug if we are all done here. Yes, I think we can colse this bug.
Frank, I just noticed that the RepositoryConfiguration serialVersionUID didn't get regenerated as part of this change. (In reply to comment #65) > Thanks for putting in this effort Charley! Is the format of the file that > specifies the workflow transitions documented anywhere? Yes, great work. A little doco on this would be excellent. Feel free to append to the Bugzilla Connector wiki: http://wiki.eclipse.org/Mylyn/Bugzilla_Connector
(In reply to comment #67) > Frank, I just noticed that the RepositoryConfiguration serialVersionUID didn't > get regenerated as part of this change. > > (In reply to comment #65) > > Thanks for putting in this effort Charley! Is the format of the file that > > specifies the workflow transitions documented anywhere? > Yes, great work. A little doco on this would be excellent. Feel free to append > to the Bugzilla Connector wiki: > > http://wiki.eclipse.org/Mylyn/Bugzilla_Connector Sure -- I've added some documentation. :) I'll work on finishing up the initial bug states and then work on filling custom workflow data from the xmlrpc.
(In reply to comment #67) > Frank, I just noticed that the RepositoryConfiguration serialVersionUID didn't > get regenerated as part of this change. Now I have update the value to fit the latest modification. Thanks Rob > > (In reply to comment #65) > > Thanks for putting in this effort Charley! Is the format of the file that > > specifies the workflow transitions documented anywhere? > Yes, great work. A little doco on this would be excellent. Feel free to append > to the Bugzilla Connector wiki: > > http://wiki.eclipse.org/Mylyn/Bugzilla_Connector
*** Bug 321058 has been marked as a duplicate of this bug. ***
*** Bug 322333 has been marked as a duplicate of this bug. ***
*** Bug 269359 has been marked as a duplicate of this bug. ***
Note that when you first point to the file on the Repository Settings Page nothing actually changes until you trigger a manual update of the repository configuration. This makes the feature look broken. To reproduce: # Add file # Click finish on repository settings page # Refresh a task (no change) # Update repository configuration # Refresh a task and you'll see changes
(In reply to comment #73) > Note that when you first point to the file on the Repository Settings Page > nothing actually changes until you trigger a manual update of the repository > configuration. This makes the feature look broken. > To reproduce: > # Add file > # Click finish on repository settings page > # Refresh a task (no change) > # Update repository configuration > # Refresh a task and you'll see changes I believe this can be fixed by calling repositoryConfiguration.setValidTransitions in BugzillaRepositorySettingsPage#applyTo. For example, see the attachment 'committed patch' from 2010-06-22, around line 1478. I'm not sure why this call to setValidTransitions was removed. With changes to the custom transitions workflow coming (bug #319295) the repository configuration updating should not be a problem in later releases. I'd be happy to take a more in depth look on Sept 5, if nobody has done so already.
see comment#74
We need to add an IRepositoryChangeListener because BugzillaRepositorySettingsPage#applyTo is called by BugzillaRepositorySettingsPage#validateSettings and EditRepositoryWizard#performFinish so we can not call repositoryConfiguration.setValidTransitions.
The changes are tracked in bug# 324525
