#1075 closed defect (fixed)
0.11 compatible version
Reported by: | Sven | Owned by: | osimons |
---|---|---|---|
Priority: | normal | Component: | XmlRpcPlugin |
Severity: | normal | Keywords: | |
Cc: | martin.marcher@…, Felix Schwarz, jgoering@…, key@… | Trac Release: | 0.11 |
Description
Create a 0.11 dev compatible version of this plugin. Seems some minor changes have to be made. Still trying to figure out which...
Attachments (19)
Change History (89)
Changed 18 years ago by
Attachment: | xmlrpc-trac-0.11.patch added |
---|
Basic patch for Trac-0.11 (fix up syntax issues)
comment:2 follow-up: 4 Changed 18 years ago by
I've added one patch for Trac milestone:0.11.
Note that the patch is not backward compatible with milestone:0.10, as there is a case-related issue (Trac files have been renamed). This means a new directory will need to be created in the SVN repos (xmlrpcplugin/0.11
)
The patch is probably not complete: I can't get the plugin to work: Trac keeps replying
HTTP error 401 (Unauthorized)
whatever the actual credentials, as well as the 'anonymous' user w/ XML_RPC
permission
comment:4 Changed 18 years ago by
Replying to eblot:
The patch is probably not complete: I can't get the plugin to work.
I'm simply stupid: this was due to an authentication mismatch issue between the XMLrpc library capabilities and the server configuration. I've added a note about authentication issue: XmlRpcPlugin#ProblemswithDigestHTTPauthentication
Anyway, the previous patch should be ok (AFAICT): XmlRpcPlugin now works fine w/ Trac 0.11
comment:5 Changed 18 years ago by
Replying to eblot:
See also ticket:4280 for the setuptools issue.
I get this exact error too. Goes away when I remove the egg
comment:6 follow-up: 9 Changed 18 years ago by
Cc: | Steffen Pingel added; anonymous removed |
---|
I get the following error when I try to run a query:
'from_string() takes exactly 4 arguments (3 given)' while executing 'ticket.query()'
comment:7 follow-up: 8 Changed 18 years ago by
And this error when I try to fetch a ticket:
'cannot marshal <type 'datetime.datetime'> objects' while executing 'ticket.get()'
comment:8 Changed 18 years ago by
Replying to stp:
And this error when I try to fetch a ticket: 'cannot marshal <type 'datetime.datetime'> objects' while executing 'ticket.get()'
I've attached a new patch that should fix up this issue. I'm not sure the date computation is correct (GMT/...) but it seems ok on my environment. I've changed the API version number, as XML RPC DateTime objects are now sent where simple integer values used to be sent for time values.
comment:9 Changed 18 years ago by
Replying to stp:
I get the following error when I try to run a query: 'from_string() takes exactly 4 arguments (3 given)' while executing 'ticket.query()'
The latest patch should fix up this issue as well.
Changed 18 years ago by
Attachment: | xmlrpc-datetime.patch added |
---|
Cumulative patch: supersedes the previous patch, add support for datetime API
comment:10 Changed 18 years ago by
Thanks. I now get the same error for ticket.changeLog(): 'cannot marshal <type 'datetime.datetime'> objects' while executing 'ticket.changeLog()'.
comment:11 Changed 18 years ago by
Here is an updated patch. I think we should introduce a third digit for the api version that marks the 0.11 branch so both branches can be evolved independently.
Changed 18 years ago by
Attachment: | xmlrpc-11.2.patch added |
---|
Cummulative patch for working xml-rpc on Trac 0.11dev-r5245
comment:12 follow-up: 16 Changed 18 years ago by
I have added a new cummulative patch that ensures the multicall method works given that it calls a variety of other methods which may contain datetime.datetime values that had marshal issues. Also, the from_string function apparently returned to only having 3 params so that was reverted.
With this patch, xml-rpc now works completely with Mylar+Eclipse on Trac 0.11dev-r5245.
comment:13 Changed 18 years ago by
I have tested the patch against the Mylar test suite without getting errors. Thanks Ben.
comment:14 follow-up: 17 Changed 18 years ago by
Hi, I have several problems with trac r5407, Mylar 2.0M3 and latest patch from ben.
Mehtod: ticket.getAvailableActions
2007-05-18 01:28:09,338 Trac[__init__] ERROR: Traceback (most recent call last): File "build/bdist.linux-i686/egg/tracrpc/xml_rpc.py", line 36, in process_request File "build/bdist.linux-i686/egg/tracrpc/api.py", line 86, in __call__ File "build/bdist.linux-i686/egg/tracrpc/ticket.py", line 67, in getAvailableActions File "/usr/lib/python2.4/site-packages/Trac-0.11dev_r5407-py2.4.egg/trac/ticket/api.py", line 401, in get_available_actions weighted_actions = controller.get_ticket_actions(req, ticket) File "/usr/lib/python2.4/site-packages/Trac-0.11dev_r5407-py2.4.egg/trac/ticket/api.py", line 165, in get_ticket_actions status = ticket['status'] or 'new' TypeError: unsubscriptable object
Method: ticket.status.get (only in eclipse, not in trac error.log)
'__init__() takes exactly 2 arguments (3 given)' while executing 'ticket.status.get()'
Other Error:
2007-05-18 00:23:52,596 Trac[__init__] ERROR: 'tracrpc/htdocs' Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/Trac-0.11dev_r5407-py2.4.egg/trac/web/main.py", line 428, in dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.4/site-packages/Trac-0.11dev_r5407-py2.4.egg/trac/web/main.py", line 216, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.4/site-packages/Trac-0.11dev_r5407-py2.4.egg/trac/web/chrome.py", line 283, in process_request for dir in [os.path.normpath(dir[1]) for dir File "build/bdist.linux-i686/egg/tracrpc/web_ui.py", line 21, in get_htdocs_dirs File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 799, in resource_filename return get_provider(package_or_requirement).get_resource_filename( File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 1229, in get_resource_filename return self._extract_resource(manager, zip_path) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 1240, in _extract_resource zip_stat = self.zipinfo[zip_path] KeyError: 'tracrpc/htdocs'
comment:15 Changed 18 years ago by
Cc: | martin.marcher@… added |
---|
comment:16 Changed 18 years ago by
Replying to ben@groovie.org:
With this patch, xml-rpc now works completely with Mylar+Eclipse on Trac 0.11dev-r5245.
Can confirm that for Trac 0.11dev-5245:
except the svn info below and genshi all I'm using are official debian/etch packages
$ python -V Python 2.4.4
trac version:
$ svn info Path: . URL: http://svn.edgewall.org/repos/trac/trunk Repository Root: http://svn.edgewall.org/repos/trac Repository UUID: af82e41b-90c4-0310-8c96-b1721e28e2e2 Revision: 5617 Node Kind: directory Schedule: normal Last Changed Author: cboos Last Changed Rev: 5616 Last Changed Date: 2007-06-06 15:11:50 +0200 (Wed, 06 Jun 2007)
xmlrpc version:
$ svn info Path: . URL: http://trac-hacks.org/svn/xmlrpcplugin/0.10 Repository Root: http://trac-hacks.org/svn Repository UUID: 7322e99d-02ea-0310-aa39-e9a107903beb Revision: 2283 Node Kind: directory Schedule: normal Last Changed Author: athomas Last Changed Rev: 2125 Last Changed Date: 2007-03-26 01:52:19 +0200 (Mon, 26 Mar 2007)
comment:17 Changed 18 years ago by
Replying to anonymous:
Hi, I have several problems with trac r5407, Mylar 2.0M3 and latest patch from ben.
Mylar indeed doesn't work but I don't get any tracebacks. Guess it's a mylar issue actually relying on an older xmlrpc version.
- Mylar Version
2.0.0.v20070514-1800
- Eclipse Version
3.2.2.r322-v20070104-dCGKm0Ln38lm-8s
same with 3.3RC3
2007-06-07 03:25:10,841 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:10,845 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:10,849 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:10,852 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:10,878 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:10,881 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:10,884 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:10,888 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:10,918 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:10,921 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:10,925 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:10,928 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:10,958 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:10,961 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:10,965 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:10,969 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,007 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,010 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,014 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,019 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,051 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,054 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,058 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,064 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,103 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,106 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,110 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,115 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,146 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,149 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,153 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,158 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,195 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,198 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,202 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,207 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,230 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,233 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,237 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,259 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,263 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,267 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,271 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]> 2007-06-07 03:25:11,301 Trac[__init__] DEBUG: Dispatching <Request "POST /xmlrpc"> 2007-06-07 03:25:11,303 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing WIKI_VIEW on <Context wiki> 2007-06-07 03:25:11,307 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing XML_RPC on <Context [root]> 2007-06-07 03:25:11,312 Trac[__init__] DEBUG: DefaultPermissionPolicy allows anonymous performing TICKET_VIEW on <Context [root]>
comment:18 Changed 17 years ago by
Cc: | ben@… added |
---|
To update this ticket, the latest from Steffen is that this plug-in needs to be updated with the latest development changes from the Trac repo. I have the Trac 0.11dev-r5849 and the MyLyn Compatibility Trac Core Plug-in 2.0.0.v20070615-compatibility plug-in. I'm certainly willing to test / help to get this working for the latest release.
Thanks.
comment:19 Changed 17 years ago by
Cc: | anonymous added; Steffen Pingel martin.marcher@… ben@… removed |
---|
The MyLyn bug URL is https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211
Changed 17 years ago by
Attachment: | xmlrpc-11.2-genshi.diff added |
---|
xmlrpc-11.2.patch converted to Genshi (no ClearSilver needed). Note the template name still ends with .cs
to make the diff more correct (works fine), but should change to .html
and update setup.py package_data if integrated into the repos.
comment:21 Changed 17 years ago by
~/xmlrpcplugin/0.10$ patch -p3 < xmlrpc-11.2-genshi.diff\?format\=raw
comment:22 follow-up: 23 Changed 17 years ago by
I have installed the latest patch (xmlrpc-11.2-genshi.diff) on Trac 0.11dev-r5982 and when I use Mylyn, I receive the following error:
Trac[init] DEBUG: No policy allowed <USERNAME> performing ATTACHMENT_CREATE on <Context u'[root], ticket:1, attachment' <Request "G ET u'/ticket/1'"> <trac.attachment.Attachment object at 0xb5f8d16c>>
Any hints? I know, that there seems to be a refactoring going on concerning the Attachement stuff, but is there right now a workaround?
comment:23 follow-up: 24 Changed 17 years ago by
Sorry, this is not XMLRPC specific. After configuring Mylyn correctly, the plugin seems to work now. Thanks for the patches. Keep up the good work :-)
comment:24 Changed 17 years ago by
Replying to mmay: Okay, I can now look up tickets in Trac via the Search (using the text-search). But I cannot access a ticket via the ID. This is due to the following error:
'init() takes exactly 2 arguments (3 given)' while executing 'ticket.status.get()'.
Any hints here? https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211
Changed 17 years ago by
Attachment: | xmlrpc-11.3-genshi.2.diff added |
---|
Patch for 0.11, Mylyn is now working :-)
comment:25 follow-up: 26 Changed 17 years ago by
Can others test this latest patch and confirm that it's working. If so I'll apply it to trunk.
comment:26 Changed 17 years ago by
Replying to athomas:
Can others test this latest patch and confirm that it's working. If so I'll apply it to trunk.
The status field is empty - anyway: big step forward!
comment:27 follow-up: 28 Changed 17 years ago by
Well from a quick test I have just done it works for me many thanks. Been missing that since I rushed in teh 0.11 update for the new ticket workflows.
comment:28 follow-ups: 29 30 Changed 17 years ago by
In order to use the context of Mylyn as well (attachment to the Ticket) please also use the following patch (not really XMLRPC related, though): http://trac.edgewall.org/attachment/ticket/5945/attachment.py.patch.
The issue status is empty? Under which condition? It works fine for me though. Please write a short reply, how I can re-test this with the status and I will try to fix it.
comment:29 follow-up: 31 Changed 17 years ago by
Replying to mmay:
The issue status is empty? Under which condition? It works fine for me though. Please write a short reply, how I can re-test this with the status and I will try to fix it.
My trac instances aren't public, so all I can give you is the attached screenshot and these information:
- trac 0.11dev-r5983
- mylyn 2.0.0.0.v20070627-1400
If I call <trac-env>/xmlrpc, I see array ticket.status.getAll()
exported
Changed 17 years ago by
Attachment: | Screenshot-Eclipse.png added |
---|
comment:30 Changed 17 years ago by
Replying to mmay:
In order to use the context of Mylyn as well (attachment to the Ticket) please also use the following patch (not really XMLRPC related, though): http://trac.edgewall.org/attachment/ticket/5945/attachment.py.patch.
This was fixed in trac:r5983.
comment:31 Changed 17 years ago by
Replying to r.sokoll@intershop.de: Hello, the log of eclipse shows: java.lang.NumberFormatException: For input string: "reopened" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.eclipse.mylyn.internal.trac.core.TracXmlRpcClient.getTicketAttributes(TracXmlRpcClient.java:527) at org.eclipse.mylyn.internal.trac.core.TracXmlRpcClient.updateAttributes(TracXmlRpcClient.java:403) at org.eclipse.mylyn.internal.trac.core.AbstractTracClient.updateAttributes(AbstractTracClient.java:148) at org.eclipse.mylyn.internal.trac.ui.wizard.TracCustomQueryPage$4.run(TracCustomQueryPage.java:391) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:113)
This is due to the fact, that the status is not anymore an AbstractEnum, therefor it is handled differently then the normal Enums (e.g. Type). This means, that the id is equal to the value of the status. So, when the status value = new, the id is new as well. Perhaps I have misunderstood the concept, but this is how it seems to be implemented right now. Probably this needs to be changed in the Mylyn Trac Plugin?
comment:32 follow-up: 33 Changed 17 years ago by
Thanks for doing all the testing! I will update the Mylyn test server to the latest version or Trac and the XmlRpcPlugin and run the test suite. I'll report the results here within the next few days.
comment:33 Changed 17 years ago by
Cc: | martin.marcher@… added; anonymous removed |
---|
Replying to stp:
Thanks for doing all the testing! I will update the Mylyn test server to the latest version or Trac and the XmlRpcPlugin and run the test suite. I'll report the results here within the next few days.
Hello,
any news on this?
comment:34 Changed 17 years ago by
Here are the stack traces from the Trac log while running the Mylyn test suite against the latest Trac trunk and XML-RPC plugin with the xmlrpc-11.3-genshi.2.diff patch applied:
2007-09-08 14:24:09,223 Trac[web_ui] ERROR: Traceback (most recent call last) : File "build/bdist.linux-i686/egg/tracrpc/web_ui.py", line 58, in process_re quest File "build/bdist.linux-i686/egg/tracrpc/api.py", line 85, in __call__ File "build/bdist.linux-i686/egg/tracrpc/ticket.py", line 45, in query TypeError: from_string() takes exactly 3 arguments (5 given)
2007-09-08 14:24:16,033 Trac[web_ui] ERROR: Traceback (most recent call last) : File "build/bdist.linux-i686/egg/tracrpc/web_ui.py", line 58, in process_re quest File "build/bdist.linux-i686/egg/tracrpc/api.py", line 85, in __call__ File "build/bdist.linux-i686/egg/tracrpc/ticket.py", line 67, in getAvailab leActions File "/home/trac/share/trac-trunk/lib/python2.4/site-packages/trac/ticket/a pi.py", line 193, in get_available_actions weighted_actions = controller.get_ticket_actions(req, ticket) File "/home/trac/share/trac-trunk/lib/python2.4/site-packages/trac/ticket/d efault_workflow.py", line 154, in get_ticket_actions status = ticket['status'] or 'new' TypeError: unsubscriptable object
comment:35 Changed 17 years ago by
Please disregard my previous comment, the egg build of the XML-RPC plugin contained old files. After doing a clean build all tests passed!
Please report any Mylyn specific errors for Trac 0.11 here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211
Alec, could you consider setting the API version to [1, 0, 0] when applying the patch? Due to the changed types (some methods return date instead of int) the API is not backwards compatible. I would like to introduce the third digit to allow evolving multiple branches (e.g. 0.10 and 0.11) separately. The first digit would indicate the branch, the second the major revision which is increased when the API changes in a non-backwards compatible way and the third digit becomes the minor version which denotes bug-fixes, API additions etc.
The only error in the Trac log was this which looks like it is to easy fix in the XML-RPC plugin:
2007-09-08 14:45:57,319 Trac[ticket] ERROR: Failure sending notification on c hange of ticket #5: unsupported operand type(s) for -: 'int' and 'datetime.da tetime' Traceback (most recent call last): File "build/bdist.linux-i686/egg/tracrpc/ticket.py", line 109, in update File "/home/trac/share/trac-trunk/lib/python2.4/site-packages/trac/ticket/n otification.py", line 81, in notify for change in TicketModule(self.env).grouped_changelog_entries( File "/home/trac/share/trac-trunk/lib/python2.4/site-packages/trac/ticket/w eb_ui.py", line 1156, in grouped_changelog_entries changelog = ticket.get_changelog(when=when, db=db) File "/home/trac/share/trac-trunk/lib/python2.4/site-packages/trac/ticket/m odel.py", line 284, in get_changelog when_ts = when and to_timestamp(when) or 0 File "/home/trac/share/trac-trunk/lib/python2.4/site-packages/trac/util/dat efmt.py", line 55, in to_timestamp diff = dt - _epoc TypeError: unsupported operand type(s) for -: 'int' and 'datetime.datetime'
comment:36 Changed 17 years ago by
I'm a little bit confused: In the plugin source, we have
- 0.10
- sandbox
- trunk
Which one should I use? If trunk, is then xmlrpc-11.3-genshi.2.diff still needed?
comment:37 follow-up: 38 Changed 17 years ago by
I ran the tests against 0.10 + patch not realizing that the patch had already been applied to trunk.
I just ran the tests again using trunk this time. Please see the attached patch which fixes an error when the comment of a wiki change is null and implements the version numbering scheme I proposed in my previous comment.
Alec, are there any plans to support updating of tickets for users without TICKET_ADMIN priviliges (http://trac-hacks.org/changeset/2614)? I am afraid requiring these privileges will make it difficult for many users to edit tickets through XML-RPC particularly in public repositories since they won't grant more than TICKET_MODIFY privileges.
comment:38 Changed 17 years ago by
Replying to stp:
I ran the tests against 0.10 + patch not realizing that the patch had already been applied to trunk.
Ahh, that is why I don't see any differences between 0.10 and trunk. Unfortunately, the status field is still empty - what makes the plugin quite unusable (nearly nobody is interested in closed tickets)
comment:39 follow-up: 40 Changed 17 years ago by
Replying to anonymous: Unfortunately, the status field is still empty - what makes the plugin quite unusable (nearly nobody is interested in closed tickets)
This sounds like a Mylyn specific problem (unless there are error stack traces in your Trac log) that should be reported here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211 .
comment:40 Changed 17 years ago by
Replying to stp:
Replying to anonymous: Unfortunately, the status field is still empty - what makes the plugin quite unusable (nearly nobody is interested in closed tickets)
This sounds like a Mylyn specific problem (unless there are error stack traces in your Trac log)
No, I don't have any stack traces in trac's log. BUT: The same Mylyn works perfectly together with a 0.10.3. If I only could provide any useful information, I would be glad to do so.
comment:41 Changed 17 years ago by
The errors you describe are caused by changes in the ticket workflow system that were made in Trac 0.11. I have committed a fix for Mylyn (which requires the XML-RPC plugin trunk + the last patch I posted here).
As I said before it is important to report errors like that in the right place otherwise reports may go unnoticed (e.g. Mylyn screen shots are only helpful in the Mylyn bug tracker). Don't worry too much about providing many details initially. You will be asked if additional information is required and it is more important to be responsive then :).
comment:42 Changed 17 years ago by
Changed 17 years ago by
Attachment: | ticket-validate.diff added |
---|
Validate permissions and ticket data before updating/creating.
comment:43 Changed 17 years ago by
Replying to stp:
Alec, are there any plans to support updating of tickets for users without TICKET_ADMIN priviliges (http://trac-hacks.org/changeset/2614)? I am afraid requiring these privileges will make it difficult for many users to edit tickets through XML-RPC particularly in public repositories since they won't grant more than TICKET_MODIFY privileges.
Agreed. It was a stop-gap measure at best.
Try this patch and let me know how it goes. It seems okay to me, but more testing would be helpful.
comment:44 Changed 17 years ago by
Cc: | Felix Schwarz added |
---|---|
Owner: | changed from Alec Thomas to Felix Schwarz |
Status: | new → assigned |
comment:45 Changed 17 years ago by
Owner: | changed from Felix Schwarz to Alec Thomas |
---|---|
Status: | assigned → new |
Sorry for spamming. The owner change happened automatically and I do not want to own this bug.
Changed 17 years ago by
Attachment: | trcxmlrpc-mylyn.png added |
---|
Status fields (like open, closed, ...) are not shown in Mylyn dialog
comment:46 follow-up: 47 Changed 17 years ago by
Trac XML-RPC r2638 and Trac r6011 (but was also present in earlier revisions): status field in Mylyn dialog (Mylyn Trac Connector 2.0.0) is not filled.
I'm really not sure if this is a Mylyn problem or a Trac XML-RPC plugin problem, but I start here ;-).
comment:47 Changed 17 years ago by
Replying to tweitzel@synformation.com:
Trac XML-RPC r2638 and Trac r6011 (but was also present in earlier revisions): status field in Mylyn dialog (Mylyn Trac Connector 2.0.0) is not filled.
I'm really not sure if this is a Mylyn problem or a Trac XML-RPC plugin problem, but I start here ;-).
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211#c13 ff.
comment:48 Changed 17 years ago by
Changed 17 years ago by
Attachment: | ExecuteAction.patch added |
---|
Patch that allows XMLRPC to execute an action
comment:49 follow-up: 50 Changed 17 years ago by
Not sure if I just missed this functionality somewhere, but I didn't find anything that lets you execute an action so I'm adding a patch for it.
comment:50 Changed 17 years ago by
Replying to markcuk:
Not sure if I just missed this functionality somewhere, but I didn't find anything that lets you execute an action so I'm adding a patch for it.
add_warning()
is not useful in an XML-RPC call. Rather, you should accumulate the warnings into a single message and raise an xmlrpclib.Fault
.
comment:51 Changed 16 years ago by
Cc: | henry78@… added |
---|
comment:52 follow-up: 53 Changed 16 years ago by
Cc: | henry78@… removed |
---|
Works for me. Didn't use the trunk version, and when i compiled trunk the old module (which i installed via easy_install) still sat in the pyhton/site-packages. I removed everything and installed from trunk, works like a charm.
comment:53 Changed 16 years ago by
Works too for me with Trac 0.11, eclipse 3.3.2, Mylyn Trac Connector 2.3.0v20080225 and XMLRPC from trunk.
comment:54 Changed 16 years ago by
Cc: | jgoering@… added |
---|
Works for the most part for me but when fetching queries with more than 100 tickets, Mylyn shows me the error dialog box:
'cannot marshal None unless allow_none is enabled' while executing 'system.multicall()'
It seems Mylyn is trying a multicall to fetch batches of 100 tickets at a time or something, and XMLRPC doesn't like it?
Any thoughts on how to fix this problem?
comment:55 Changed 16 years ago by
More info on this: it's not the fetching of so many tickets but rather that one of my custom fields had the value not set.
Changed 16 years ago by
Attachment: | NoneMarshalErrorChangeLog.patch added |
---|
pach to allow_none marshal error
comment:56 Changed 16 years ago by
Hi,
The ticket.changeLog() has no check for possible errors like: deleted user(author) or field so an None is submitted to xmlrpclib.dumps ant it raises the exception. The Trac backend for Mylyn 3.3/3.4 doesn't understand None either so those variables must return some string.
patch attached attachment:NoneMarshalErrorChangeLog.patch
comment:57 Changed 16 years ago by
Cc: | key@… added |
---|
Changed 16 years ago by
comment:58 Changed 16 years ago by
Just wondering if there is going to be a formal release of the plugin for trac 0.11.
Thanks
comment:59 Changed 16 years ago by
see here: http://sourceforge.net/tracker/index.php?func=detail&aid=2672182&group_id=1&atid=350001 for the version used on sourceforge.
Changed 16 years ago by
Attachment: | ticket_workflow-r3074.diff added |
---|
Workflow support for xmlrpc plugin
comment:62 follow-up: 63 Changed 16 years ago by
Owner: | changed from Alec Thomas to osimons |
---|
I've tried to solve the main remaining issue for 0.11 support of the plugin - ticket workflow.
The patch does the following:
1) Removes 'status' from supported interfaces. This is done workflow only now, so creating and manipulating just does not make sense. See also #5268.
2) Replaces ticket.getAvailableActions()
with ticket.getActions()
that is much smarter about what it finds - and the information it provides. It will return a list [action, [inputs]]
elements, so that if the action takes an input this will be populated - like for instance a resolve
action will have an input with the variable that needs to be populated to send the correct resolution. To illustrate this, here is the output of getActions()
from a stock Trac install and using default workflow:
[['leave', []], ['resolve', [['action_resolve_resolve_resolution', 'fixed', ['fixed', 'invalid', 'wontfix', 'duplicate', 'worksforme']]]], ['reassign', [['action_reassign_reassign_owner', 'anonymous', []]]], ['accept', []]]
The inputs (can be more than one of course) are of the form [<var_name>, <default_or_current_value>, [options]]
- the resolve
in example above shows that quite clearly. And, if the env had the setting to restrict owner on tickets, the options would similarly be populated with the allowed user names.
The routine is workflow-agnostic, and SHOULD (...) support any kind of workflow controller - or set of active controllers. Not exactly tested, so testing most welcome. At least there is nothing in there specific to the default workflow - it just reads and gathers data and passes it on.
3) ticket.create()
is just modified slightly to make all created tickets new
as that is a Trac presumption that follows workflows.
4) ticket.update()
has seen much change, and the key difference is that attributes
dict should contain an 'action'. All updates of any kinds should have it - even if the action is just 'leave'
for the do-nothing action. If action is missing, the method behaves as before - not safe, not recommended, and a warning is logged. But ticket is still saved as before. The action is of course as fetched from the new getAction()
including any other fields as specified by possible inputs for that action.
All fields except 'status' and 'owner' are allowed to update via attributes. Those fields are now reserved for workflow actions. Perhaps other workflow plugins would like to reserve other fields, but I have no plan for that now. Not sure how to solve arbitrary field blocking as the Trac workflow api provides no help in discovering them.
The updating with 'action' is now done by going through the various steps in the TicketModule
for getting changes, validating and so on. If anything was disallowed by using web frontend, it should also raise an error when tried through rpc. It will collect warnings and raise all problems. No problems and all is fine, the ticket is saved and the updated ticket returned (same behavior as before).
...
This patch requires testing, and it would also be helpful to get feedback developers that need to use this quite heavily. Feedback?
comment:63 Changed 16 years ago by
Thanks for the great patch! I have implemented a first proto-type for Mylyn that takes advantage of the new API. I have commented below with a suggestions.
1) Removes 'status' from supported interfaces. This is done workflow only now, so creating and manipulating just does not make sense. See also #5268.
It would be great if the API still supported discovering all available statuses. This would enable clients to provide a list of statuses for filtering. The web interface has this when creating custom queries. This could be as simple as a getAllStatuses() method that returns a list of strings.
2) Replaces
ticket.getAvailableActions()
withticket.getActions()
that is much smarter about what it finds - and the information it provides. It will return a list[action, [inputs]]
elements, so that if the action takes an input this will be populated - like for instance aresolve
action will have an input with the variable that needs to be populated to send the correct resolution. To illustrate this, here is the output ofgetActions()
from a stock Trac install and using default workflow:[['leave', []], ['resolve', [['action_resolve_resolve_resolution', 'fixed', ['fixed', 'invalid', 'wontfix', 'duplicate', 'worksforme']]]], ['reassign', [['action_reassign_reassign_owner', 'anonymous', []]]], ['accept', []]]
This looks good. It would be great if the label and hint for actions could be included as well. That way clients could match the presentation in the web interface better.
3)
ticket.create()
is just modified slightly to make all created ticketsnew
as that is a Trac presumption that follows workflows.
Seems to work fine.
4)
ticket.update()
has seen much change, and the key difference is thatattributes
dict should contain an 'action'. All updates of any kinds should have it - even if the action is just'leave'
for the do-nothing action. If action is missing, the method behaves as before - not safe, not recommended, and a warning is logged. But ticket is still saved as before. The action is of course as fetched from the newgetAction()
including any other fields as specified by possible inputs for that action.All fields except 'status' and 'owner' are allowed to update via attributes. Those fields are now reserved for workflow actions. Perhaps other workflow plugins would like to reserve other fields, but I have no plan for that now. Not sure how to solve arbitrary field blocking as the Trac workflow api provides no help in discovering them.
Is the fact that the owner can not be changed a limitation of Trac? This is an unfortunate change in the repository behavior which will require an additional round-trip when a ticket is closed and the owner should be changed at the same time.
Some additional thoughts:
- The version number of the plug-in should be increased to 2.0.0 since methods have been removed which constitutes a breaking API change.
- The updateTicket() method should now only require TICKET_MODIFY instead of TICKET_ADMIN privileges.
Changed 16 years ago by
Attachment: | t1075-ticket_workflow2-r3074.diff added |
---|
Updated patch - further fixes and improvements following research and suggestions.
comment:64 follow-up: 65 Changed 16 years ago by
Thanks for testing and feedback.
I've attached an updated patch that futher improves things:
- I want to avoid API removal at this stage, so I'm adding back the
status
group of methods.getAll()
works as before, but now it retrieves all the states as defined by active workflow. All other methods are noop methods replacing methods that did not work anyway. At least the API stays the same, and the noop methods are clearly marked as deprecated. See #5268. update()
now hasTICKET_VIEW
as lowest possible permission. In reality, eitherTICKET_CHGPROP
orTICKET_APPEND
is needed depending on what update contains. May throw permission errors on validation, but that is to be expected anyway. See #3642.- I've given thought to updating fields directly that is also part of workflow - specifically the request in comment:63 about 'owner'. As mentioned, the problem is that there is no way to detect what fields a given action could operate on. I'm OK with reserving just 'status' and 'resolution' (new) for workflow - and leaving all other fields to be updated if the user so wishes.
- The patch has some general improvements for correct workflow handling thanks to review by retracile - most importantly allowing all controllers to possibly operate on an action, as well as remembering to apply side-effects of updates.
- I've not implemented labels and hints for actions as suggested by comment:63. The API in general has no such support, and I don't think I'll start this now. I expect users to know their own Trac setup with regards to what fields do and how actions are used. If anything it will be an excercise for a future Trac 0.12 that if so also would need to localize this information...
It will be applied shortly unless someone screams. As it should be API-compatible, the only effect should be that things are starting to behave as expected...
Changed 16 years ago by
Attachment: | t1075-ticket_workflow3-r3074.diff added |
---|
Added label and hint and increased version to 1.1.0
Changed 16 years ago by
Attachment: | t1075-ticket_workflow4-r3074.diff added |
---|
renamed TicketStatusRPC back to StatusRPC and updated documentation for getActions()
comment:65 follow-up: 66 Changed 16 years ago by
- I want to avoid API removal at this stage, so I'm adding back the
status
group of methods.getAll()
works as before, but now it retrieves all the states as defined by active workflow. All other methods are noop methods replacing methods that did not work anyway. At least the API stays the same, and the noop methods are clearly marked as deprecated. See #5268.
Great! That works perfectly. The only change I made in the last patch is to rename the plugin component back to the original name.
- I've given thought to updating fields directly that is also part of workflow - specifically the request in comment:63 about 'owner'. As mentioned, the problem is that there is no way to detect what fields a given action could operate on. I'm OK with reserving just 'status' and 'resolution' (new) for workflow - and leaving all other fields to be updated if the user so wishes.
Great! Thanks.
- I've not implemented labels and hints for actions as suggested by comment:63. The API in general has no such support, and I don't think I'll start this now. I expect users to know their own Trac setup with regards to what fields do and how actions are used. If anything it will be an excercise for a future Trac 0.12 that if so also would need to localize this information...
Can you take a look at my changes? I grabbed the values from the action controller. The presentation in Mylyn is much, e.g. "Failed testing, return to developer" instead of "reject".
Sorry to be nitpicky about the version. It should be incremented to 1.1.0 since the API has changed (a new methods was added).
This is really coming along nicely. It would be awesome if a new release of the XmlRpcPlugin was available by June 24th (Mylyn 3.2 release date). That way the next Mylyn release could take advantage of the new API and Trac 0.11 users would finally get proper work flow support in Mylyn.
comment:66 Changed 16 years ago by
Sorry to be nitpicky about the version. It should be incremented to 1.1.0 since the API has changed (a new methods was added).
Never mind this comment. Looking at the documentation 1.0.1 is the correct version.
Changed 16 years ago by
Attachment: | t1075-ticket_workflow5-r3074.diff added |
---|
Last one :-) Minor tweaks.
comment:67 Changed 16 years ago by
Ok, ok. Label and hints are in. Forgot to update method docs before submitting, but got it fixed locally. Also renamed to StatusRPC
as requested - no biggie.
One final thing I've done locally is also to scrap the restriction on not being able to update 'resolution' - it makes no more or less sense than resticting 'owner'. And there are good use-cases for updating a ticket closed as wrong resolution without changing the status of the ticket.
This is it. This will be in repos shortly. Thanks for testing and constructive feedback!
comment:68 Changed 16 years ago by
(In [6045]) XmlRpcPlugin: Workflow support - finally!
- Adds workflow support and improved ticket creation and update to be aligned with recent Trac 0.11.x features. See #1075 for all details.
- As workflow controls permissions for actions,
update()
permission is changed toTICKET_VIEW
, closing #3642. - With workflow and 'action' support, users are also available for reassignment if the project is configured to restrict ticket owners. This should close #1010.
- As 'status' is now the domain of workflow, these status-manipulation methods are now deprecated and replaced with no-op versions for compatibility. That should take care of #5268.
Version bumped to 1.0.1.
comment:69 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'm closing this ticket now - it has become unmanageable for any other 0.11 issues that remain (and there are some). For new issues, please open new tickets.
comment:70 Changed 16 years ago by
Thanks a lot for all your efforts! I have published a new weekly build for Mylyn that takes advantage of the new workflow support:
175211: Support Trac 0.11 https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211