Bugzilla – Full Text Bug Listing
| Summary: | basic Trac connector | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Steffen Pingel <steffen.pingel> | ||||
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | eclipse.dserodio, ekuleshov, gunnar, pombredanne, tvanlessen | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 147816 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Steffen Pingel
This sounds right Steffen, just skip the "adding of existing" for the first iteration and focus on tests and wiring up of the queries. Note that some of the classes that you'll be extending will be changing, but I will walk you through that as it happens. BTW, it looks like Mylar's URL finder fail to properly select URL from the description of this bug report. Eugene, if you're talking about an error dialog that pops up stating that the title could not be downloaded, that's a timeout and the message will be made silent once the web integration gets released. (In reply to comment #3) > Eugene, if you're talking about an error dialog that pops up stating that the > title could not be downloaded, that's a timeout and the message will be made > silent once the web integration gets released. No, it is about decorator that you see in the Bugzilla editor. It adds "):" to the end of the url. Regarding comment #4, I added bug 146964. Mik, to follow up on the conference call: You mentioned some kind of wiki integration for Mylar that is being done for Confluence. I haven't quite grasped the concept, yet. Is there more information available? A few suggestions for minor changes to the API have come up: * The signature of AbstractRepositoryConnector.canCreateTask() should include an instance of TaskRepository. For Trac the availability of this operation depends on the permissions of the logged in user and may vary on a repository basis. * The signature of AbstractRepositoryConnector.createTaskFromExistingKey() could be extended to include an IProgressMonitor since this operation requires remote access and can take a long time. * The visibility of AbstractRepositorySettingsPage.RepositoryStringFieldEditor should be changed to protected. Otherwise a cast is required to access the password editor ((StringFieldEditor)passwordEditor) in classes that extend AbstractRepositorySettingsPage. Trac supports access without authentication, so it would be nice to have an "Anonymous access" check box that disabled the username and password editor. (In reply to comment #7) > * The visibility of AbstractRepositorySettingsPage.RepositoryStringFieldEditor > should be changed to protected. Otherwise a cast is required to access the > password editor ((StringFieldEditor)passwordEditor) in classes that extend > AbstractRepositorySettingsPage. Trac supports access without authentication, so > it would be nice to have an "Anonymous access" check box that disabled the > username and password editor. For this one I think would be better to use custom settings page that connector could provide and which will be replacing the standard one. I also need this feature for generic web0based provider. (In reply to comment #8) > For this one I think would be better to use custom settings page that > connector could provide and which will be replacing the standard one. > I also need this feature for generic web0based provider. Alright, that certainly makes sense, since time zone and character encoding are fixed for Trac (always UTC and UTF-8). I still think it is not good practice to have a protected field with a private type. Changing the type of passwordEditor to StringFieldEditor would also do the job. Steffen: Eugene has implemented the custom settings and those are now committed. Let me know if anything else needs to be opened up there. I gave AbstractAddExistingTaskWizard a setNeedsProgressMonitor(true). If you would like to pass the monitor to the connector you can submit a patch for that, but we'll have to make that consistent with Bugzilla which currently closes the Wizard and runs a job for retrieving the task. Regarding the canCreate*Task() methods, this is a repository capability and not a task capability. So this check would have to happen after the repository was selected. Could you just handle the error for now, and submit a patch if you would like to add this check to that stage of the wizard (perhaps disabling the widgets for the repositories that do not accept new reports being added?). As you should break out the items in the description into seperate bug reports, probably one at a time as you do them, and then submit patches to those. We can keep this one open for general discussion. (In reply to comment #10) > Regarding the canCreate*Task() methods, this is a repository capability and not > a task capability. So this check would have to happen after the repository was > selected. Could you just handle the error for now, and submit a patch if you > would like to add this check to that stage of the wizard (perhaps disabling the > widgets for the repositories that do not accept new reports being added?). +1 for adding repository instance to the canCreate*() methods, since it is used from the list of repository instances anyways. In web-based repository provider I would check if repository has url defined for creating new tasks. Yes, for Trac I could check the access type (xml-rpc vs. query) when the new task wizard is opened. I would prefer not to display the task repository in the list if I know beforehand that creating new tasks is not possible. (In reply to comment #10) > Steffen: Eugene has implemented the custom settings and those are now > committed. Let me know if anything else needs to be opened up there. The settings are fine. I am still thinking about opening a request to refactor AbstractRepositorySettingsPage to make it more flexible. I am hesitant to copy&pasting most part of it to create a settings page for Trac. > I gave AbstractAddExistingTaskWizard a setNeedsProgressMonitor(true). If you > would like to pass the monitor to the connector you can submit a patch for > that, but we'll have to make that consistent with Bugzilla which currently > closes the Wizard and runs a job for retrieving the task. I have to think about that. Closing the wizard and synchronizing the task in the background seems like a good idea. I was looking at the Jira code that fetches the task in a blocking way. > Regarding the canCreate*Task() methods, this is a repository capability and not > a task capability. I have opened bug 147609 for that. I have opened bug 147816 for the implementation of core and model. Created attachment 45541 [details]
Instructions for building Trac connector
Patch for the Mylar Contributor Reference as discussed on the Mylar devel mailing list.
Thanks Steffen, I plan to apply on Tuesday. Once the outstanding patches for bug 147816 and bug 147817 have been merged, I will start working on bug 149385 (adding of existing tasks) and bug 149386 (query support). Docs patch applied and pushed to web, and patches on the other reports applied as well. What you should implement now is the org.eclipse.mylar.tasklist.repositories extension point, using ..mylar.jira/plugin.xml as an example. Then once you have bug 149385 working please post the test repository details on it. (In reply to comment #18) > Then once you have bug 149385 working please post the test repository > details on it. Anonymous access using Trac 0.9 as an access type should work on all public Trac repositories that allow custom queries (which is the default). To try out XML-RPC you can use: http://trac.steffenpingel.de/mylar-test Username: trac-test Password: trac-test My repository uses Digest HTTP authentication, will you add support for that? (In reply to comment #20) > My repository uses Digest HTTP authentication, will you add support for that? Sounds like a nice to have feature. Please file a new report for that. (In reply to comment #21) > (In reply to comment #20) > > My repository uses Digest HTTP authentication, will you add support for that? > > Sounds like a nice to have feature. Please file a new report for that. > There is no "Trac" component in Bugzilla for Mylar. Which component should I choose for this report? > There is no "Trac" component in Bugzilla for Mylar. Which component should I
> choose for this report?
You can use "Core".
Basic connector is working now--if anyone is having trouble with it please file a new bug to the new Trac component in Bugzilla. |