Community
Participate
Working Groups
Provide support for querying Trac repositories. The query wizard could resemble the interface of Trac's custom query page: https://oss.steffenpingel.de/mylar-trac-connector/query . Search criteria can be added as needed which avoids a cluttered ui.
Steffen, in doing this I think we should consider generalizing the current search facilities and UI so that we don't end up with 3 different UIs and implementations. This is bug 142783. It could be good to use Trac as a driver.
Regarding comment#1, don't let this stop you from coming up with a very basic query UI, and base it on the way Bugzilla does it.
I will try to have something ready by tomorrow so you can have a look at the UI and we can discuss a common look and feel for all connectors.
Created attachment 45901 [details] Query support The patch contains query support and a first proto-type of the query dialog. I'll provide test cases (and fixes) tomorrow. Mik, could you please have a look at the dialog and provide some feedback wether you like the way search filters are added on-demand similar to the Trac web interface?
Created attachment 45902 [details] mylar/context/zip
Patch applied. However, I couldn't make a query work on edgewall since with the various ones I tried caused the following exception. I'll take Trac out of the dev build for tonight, but let's try to get it into a dev build for people to try out next week since it seems that you are almost there. Regarding the on-demand appearence of parameters, I think that it is too unclear when first opened and results in too many clicks for a typical query. You should assume that you have as much space as the Bugzilla dialog to fill with useful query paramter setting, and it looks like that's all you'll need. Only if that much were filled would we need an adapting UI for toggling more/less parameters. Having it be static also helps users become accustomed to the layout. java.lang.NullPointerException at org.eclipse.mylar.internal.trac.TracRepositoryConnector.updateTaskDetails(TracRepositoryConnector.java:261) at org.eclipse.mylar.internal.trac.TracRepositoryConnector.performQuery(TracRepositoryConnector.java:194) at org.eclipse.mylar.provisional.tasklist.SynchronizeQueryJob.run(SynchronizeQueryJob.java:75) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Created attachment 45979 [details] Fix for NullPointerException and test cases Looks like Edgewall uses customized priorities which weren't correctly handled and caused the exception.
So there's an interesting question about how you could handle customized priorities... in Bugzilla we simply rely on the order in which they are returned, thereby supporting any names for them (unlike JIRA). In the meantime make the failure failure mode be setting the default priority and write a test that issues a priority you can't prase. Is there another test server I should use?
(In reply to comment #6) > Patch applied. However, I couldn't make a query work on edgewall since with > the various ones I tried caused the following exception. I'll take Trac out of > the dev build for tonight, but let's try to get it into a dev build for people > to try out next week since it seems that you are almost there. Maybe we should change the url hint that is displayed on the repository properties page to something other than the edgewall repository. They have many tasks and I wouldn't want to cause a heavy load on their server by many people testing queries. > Regarding the on-demand appearence of parameters, I think that it is too > unclear when first opened and results in too many clicks for a typical query. True, it would be better to display most commonly used search filters by default. > You should assume that you have as much space as the Bugzilla dialog to fill > with useful query paramter setting, and it looks like that's all you'll need. > Only if that much were filled would we need an adapting UI for toggling > more/less parameters. Having it be static also helps users become accustomed > to the layout. Alright. I'll try to figure out what can be reused in terms of look and feel from the Bugzilla search dialog and commit a patch at the beginning of next week.
(In reply to comment #8) > So there's an interesting question about how you could handle customized > priorities... in Bugzilla we simply rely on the order in which they are > returned, thereby supporting any names for them (unlike JIRA). When XML-RPC is used a list of priorities can be queried that contains a name and an integer value for each priority. When Trac's query script is used there is no way to find out about the order of priorities unless some HTML parsing is done. I am thinking about parsing the "New Ticket" page (e.g. http://trac.steffenpingel.de/mylar-test/newticket) which has all information needed. I certainly want to implement this for XML-RPC first and have the query dialog combo boxes and lists with priorities, milestones etc. instead of just text fields. > Is there another test server I should use? You can try the test repository at bug 146334 comment #19 which can be accessed through XML-RPC.
I think that it's good to leave their repository as an example and don't imagine that people would add queries unless they were interested in something there. Also, it's key that the connector support the Trac repository itself. I tried that repository but did not find any tickets either via the connector or via the web UI. So what's left before we can get this out for people to try? Seems like: 1) fixing the crash with priorities (parsing just newticket is OK if that will make this work, but ignoring priorities for now is fine too) 2) flattening the query page as per comment#6 Regarding the two 'capabilities', just to make sure I have this straight the Trac XML-RPC stuff is version 0.10 only, and Edgewall has not updated to this version yet? Any idea when they will?
(In reply to comment #11) > I tried that repository but did not find any tickets either via the connector > or via the web UI. Edgewall moved their repository to http://trac.edgewall.org on Monday. The redirect from the old location may not be handled correctly. I just tried a query "Milestone is 0.10" which returns a bunch of tickets. Did you apply the patch submitted in comment #7 before running the query? > So what's left before we can get this out for people to try? Seems like: > 1) fixing the crash with priorities (parsing just newticket is OK if that will > make this work, but ignoring priorities for now is fine too) Since priorities are stored as strings by ITask, would it be okay to set the value returned by the repository (e.g. "high")? Or do these always need to mapped to Mylar priorites ("P1", "P2"...)? > 2) flattening the query page as per comment#6 I am currently working on that. I am basing the new version on BugzillaSearchPage. So far it looks like there is some potential for a common abstract implementation. > Regarding the two 'capabilities', just to make sure I have this straight the > Trac XML-RPC stuff is version 0.10 only, and Edgewall has not updated to this > version yet? Any idea when they will? As far as I know the Edgewall repository runs some current trunk version of Trac but they don't have the XML-RPC plugin installed in their repository. I don't think they would do that without good reason. Even if they did this would still require special privileges probably only granted to registered users (i.e. Trac comitters).
I failed to notice the patch from comment#7, applied now, and queries to edgewall are working very nicely :) Regarding priorities, you need to do what JIRA does, which means doing the mapping (at least for now). The Px values are just used for externalization and identifying the order, and the Trac UI could show the actual values. Is the natural split for this connector not to support advanced integration (e.g. rich editor) without the XML RPC plug-in being enabled? That seems like a fine split. Could you create a new bug report for Edgewall to enable the XML-RPC plug-in, citing the Trac Connector as the driver, and CC me? Problem: the connector is making way too many calls to: MylarTaskListPlugin.getTaskListManager().getTaskList().notifyLocalInfoChanged(task); from updateTaskDetails(..). Each one of these calls causes the task list to get saved and a refresh of the list, hence the flickering you see when synchronizing a Trac query. It will also cause errors in the log when a query is still running during shutdown. Nits: 1) on the Add Task Repository page the Trac icon should show up (add via extension point, image is already in CVS) 2) on the same page the support versions should be listed as with the other plug-ins 3) update the Example URL on the Trac settings page. 4) synching Trac queries causes a lot of Task List refresh (notice blinking), please investigate and let me know where it's happening so I can point you at the right way of triggering refresh 5) I get the following test failure (1 failed out of 71) junit.framework.ComparisonFailure: expected:<456: mysummary> but was:<> at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.eclipse.mylar.trac.tests.TracRepositoryConnectorTest.testUpdateTaskDetailsSummaryOnly(TracRepositoryConnectorTest.java:202) Once the above is done I think we should be ready to put out a dev build and announce this on mylar-dev for people to try out.
Hi, > Regarding priorities, you need to do what JIRA does, which means doing the > mapping (at least for now). The Px values are just used for externalization > and identifying the order, and the Trac UI could show the actual values. Okay. I'll use P3 as a default priority in case the priority can't be mapped. > Is the natural split for this connector not to support advanced integration > (e.g. rich editor) without the XML RPC plug-in being enabled? Yes. > Problem: the connector is making way too many calls to > [...]notifyLocalInfoChanged(task); Oops. I have added boolen flag that will skip the nofication when retrieving query results. > 4) synching Trac queries causes a lot of Task List refresh (notice blinking), > please investigate and let me know where it's happening so I can point you at > the right way of triggering refresh I guess this is caused by the superfluous calls to notifyLocalInfoChanged() and should be easy to fix. I will submit a patch with the updated query dialog and fixes for issues mentioned in comment #13 later today.
Created attachment 46199 [details] Query dialog based on Bugzilla's query dialog and fixes The patch contains the new query dialog. Updating of repository attributes (milestones, versions...) has only implemented for XML-RPC so far. I'll look into getting the neccessary information for query script access. I am also thinking about implementing support for URL based queries (similiar to the Bugzilla connector). That way existing queries could be easily "imported" into Mylar. The patch also includes fixes for issues mentioned in comment #13.
Created attachment 46218 [details] Enhanced query dialog based on Bugzilla's query dialog and fixes Attribute fetching now also works for query script repositories. The information still is not cached. Once this patch has been merged I'll work on that.
Created attachment 46274 [details] Updated patch
There are few minor fixes you need to make due to the refactoring to get rid of conflicts in this patch (e.g. MylarTaskListPlugin -> TasksUiPlugin). I'll apply it right away after you post so that we can try to get this out today. Yes, storing queries in URL-based form is definitely the way to go because it is a concise and robust form, and enables interoperability with the Web UI.
Created attachment 46298 [details] Updated patch
*Very* nice Steffen. I did some manual testing and everything works. Search attributes don't get persisted on reopening the query so "Update" has to be pressed again, but don't fix this yet because we should generalize Bugzilla's support for saving those attributes. Please create a new but report for that. I will try to cut a developer build soon, you should do some testing on that, and then we'll announce it. I assume that we should point people to the edgewall repository as the example?
I have opened bug 150670 (persist attributes). I will submit a small patch for that bug report which will at least cache the information through Eclipse sessions and we can add on-disk persistance later. Yes, the Edgewall repository should be fine. I could also add a template to the repository settings page for that.
Yes, do that once Rob has bug 150430 resolved.
I have opened bug 150677 for adding the repository templates.
