Modify

Opened 18 years ago

Closed 15 years ago

Last modified 15 years ago

#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)

xmlrpc-trac-0.11.patch (926 bytes) - added by Emmanuel Blot 18 years ago.
Basic patch for Trac-0.11 (fix up syntax issues)
xmlrpc-datetime.patch (5.7 KB) - added by Emmanuel Blot 18 years ago.
Cumulative patch: supersedes the previous patch, add support for datetime API
xmlrpc-trac-0.11-1.patch (6.0 KB) - added by Steffen Pingel 18 years ago.
Fix for get_changelog
xmlrpc-11.2.patch (6.3 KB) - added by ben@… 18 years ago.
Cummulative patch for working xml-rpc on Trac 0.11dev-r5245
xmlrpc-11.2-genshi.diff (11.4 KB) - added by osimons 17 years ago.
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.
xmlrpc-11.3-genshi.diff (11.4 KB) - added by mmay 17 years ago.
Patch for 0.11
xmlrpc-11.3-genshi.2.diff (11.4 KB) - added by mmay 17 years ago.
Patch for 0.11, Mylyn is now working :-)
Screenshot-Eclipse.png (56.9 KB) - added by Rainer Sokoll 17 years ago.
xmlrpcplugin-trunk.patch (1.9 KB) - added by Steffen Pingel 17 years ago.
fixes for trunk
ticket-validate.diff (2.2 KB) - added by Alec Thomas 17 years ago.
Validate permissions and ticket data before updating/creating.
trcxmlrpc-mylyn.png (33.4 KB) - added by tweitzel@… 17 years ago.
Status fields (like open, closed, ...) are not shown in Mylyn dialog
ExecuteAction.patch (2.6 KB) - added by Mark Curtis 17 years ago.
Patch that allows XMLRPC to execute an action
NoneMarshalErrorChangeLog.patch (778 bytes) - added by zefyrus@… 16 years ago.
pach to allow_none marshal error
setup.py (421 bytes) - added by anonymous 16 years ago.
ticket_workflow-r3074.diff (7.4 KB) - added by osimons 15 years ago.
Workflow support for xmlrpc plugin
t1075-ticket_workflow2-r3074.diff (10.4 KB) - added by osimons 15 years ago.
Updated patch - further fixes and improvements following research and suggestions.
t1075-ticket_workflow3-r3074.diff (10.5 KB) - added by Steffen Pingel 15 years ago.
Added label and hint and increased version to 1.1.0
t1075-ticket_workflow4-r3074.diff (10.5 KB) - added by Steffen Pingel 15 years ago.
renamed TicketStatusRPC back to StatusRPC and updated documentation for getActions()
t1075-ticket_workflow5-r3074.diff (10.6 KB) - added by osimons 15 years ago.
Last one :-) Minor tweaks.

Download all attachments as: .zip

Change History (89)

comment:1 Changed 18 years ago by serega

Changed 18 years ago by Emmanuel Blot

Attachment: xmlrpc-trac-0.11.patch added

Basic patch for Trac-0.11 (fix up syntax issues)

comment:2 Changed 18 years ago by Emmanuel Blot

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:3 Changed 18 years ago by Emmanuel Blot

See also ticket:4280 for the setuptools issue.

comment:4 in reply to:  2 Changed 18 years ago by Emmanuel Blot

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 in reply to:  3 Changed 18 years ago by anonymous

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 Changed 18 years ago by Steffen Pingel

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 Changed 18 years ago by Steffen Pingel

And this error when I try to fetch a ticket:

'cannot marshal <type 'datetime.datetime'> objects' while executing 'ticket.get()'

comment:8 in reply to:  7 Changed 18 years ago by Emmanuel Blot

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 in reply to:  6 Changed 18 years ago by Emmanuel Blot

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 Emmanuel Blot

Attachment: xmlrpc-datetime.patch added

Cumulative patch: supersedes the previous patch, add support for datetime API

comment:10 Changed 18 years ago by Steffen Pingel

Thanks. I now get the same error for ticket.changeLog(): 'cannot marshal <type 'datetime.datetime'> objects' while executing 'ticket.changeLog()'.

Changed 18 years ago by Steffen Pingel

Attachment: xmlrpc-trac-0.11-1.patch added

Fix for get_changelog

comment:11 Changed 18 years ago by Steffen Pingel

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 ben@…

Attachment: xmlrpc-11.2.patch added

Cummulative patch for working xml-rpc on Trac 0.11dev-r5245

comment:12 Changed 18 years ago by ben@…

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 Steffen Pingel

I have tested the patch against the Mylar test suite without getting errors. Thanks Ben.

comment:14 Changed 17 years ago by anonymous

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 17 years ago by anonymous

Cc: martin.marcher@… added

comment:16 in reply to:  12 Changed 17 years ago by anonymous

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 in reply to:  14 Changed 17 years ago by anonymous

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 roymartin

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 roymartin

Cc: anonymous added; Steffen Pingel martin.marcher@… ben@… removed

Changed 17 years ago by osimons

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:20 Changed 17 years ago by Rainer Sokoll

How do I apply xmlrpc-11.2-genshi.diff?

comment:21 Changed 17 years ago by Steffen Pingel

~/xmlrpcplugin/0.10$ patch -p3 < xmlrpc-11.2-genshi.diff\?format\=raw

comment:22 Changed 17 years ago by mmay

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 in reply to:  22 ; Changed 17 years ago by mmay

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 in reply to:  23 Changed 17 years ago by anonymous

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 mmay

Attachment: xmlrpc-11.3-genshi.diff added

Patch for 0.11

Changed 17 years ago by mmay

Attachment: xmlrpc-11.3-genshi.2.diff added

Patch for 0.11, Mylyn is now working :-)

comment:25 Changed 17 years ago by Alec Thomas

Can others test this latest patch and confirm that it's working. If so I'll apply it to trunk.

comment:26 in reply to:  25 Changed 17 years ago by Rainer Sokoll

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 Changed 17 years ago by kev@…

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 in reply to:  27 ; Changed 17 years ago by 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.

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 in reply to:  28 ; Changed 17 years ago by Rainer Sokoll

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 Rainer Sokoll

Attachment: Screenshot-Eclipse.png added

comment:30 in reply to:  28 Changed 17 years ago by Alec Thomas

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 in reply to:  29 Changed 17 years ago by anonymous

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 Changed 17 years ago by Steffen Pingel

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 in reply to:  32 Changed 17 years ago by martin.marcher@…

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 Steffen Pingel

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 Steffen Pingel

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 Rainer Sokoll

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?

Changed 17 years ago by Steffen Pingel

Attachment: xmlrpcplugin-trunk.patch added

fixes for trunk

comment:37 Changed 17 years ago by Steffen Pingel

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 in reply to:  37 Changed 17 years ago by anonymous

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 Changed 17 years ago by Steffen Pingel

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 in reply to:  39 Changed 17 years ago by Rainer Sokoll

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 Steffen Pingel

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 Alec Thomas

(In [2624]) Applied a patch (refs #1075) from stp which fixes some more 0.11 problems. Thanks!

Changed 17 years ago by Alec Thomas

Attachment: ticket-validate.diff added

Validate permissions and ticket data before updating/creating.

comment:43 Changed 17 years ago by Alec Thomas

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 Felix Schwarz

Cc: Felix Schwarz added
Owner: changed from Alec Thomas to Felix Schwarz
Status: newassigned

comment:45 Changed 17 years ago by Felix Schwarz

Owner: changed from Felix Schwarz to Alec Thomas
Status: assignednew

Sorry for spamming. The owner change happened automatically and I do not want to own this bug.

Changed 17 years ago by tweitzel@…

Attachment: trcxmlrpc-mylyn.png added

Status fields (like open, closed, ...) are not shown in Mylyn dialog

comment:46 Changed 17 years ago by tweitzel@…

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 in reply to:  46 Changed 17 years ago by Rainer Sokoll

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 martin@…

Hello,

just installed r2917 from trunk and it "just works" with trac0.11.

our trac is: r5617

if anyones interested. I tested with mylyn with

  • eclipse 3.2 where the attributes didn't update properly. But basic work was possible
  • eclipse 3.3 - all worked

hth martin

Changed 17 years ago by Mark Curtis

Attachment: ExecuteAction.patch added

Patch that allows XMLRPC to execute an action

comment:49 Changed 17 years ago by Mark Curtis

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 in reply to:  49 Changed 17 years ago by anonymous

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 Henry78

Cc: henry78@… added

comment:52 Changed 16 years ago by Henry78

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 in reply to:  52 Changed 16 years ago by CN

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 anonymous

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 jgoering@…

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 zefyrus@…

pach to allow_none marshal error

comment:56 Changed 16 years ago by zefyrus@…

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 anonymous

Cc: key@… added

Changed 16 years ago by anonymous

Attachment: setup.py added

comment:58 Changed 16 years ago by anonymous

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 rupert thurner

comment:60 Changed 16 years ago by rupert thurner

see also #3310

comment:61 Changed 16 years ago by rupert thurner

#3110 that is ...

Changed 15 years ago by osimons

Attachment: ticket_workflow-r3074.diff added

Workflow support for xmlrpc plugin

comment:62 Changed 15 years ago by osimons

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 in reply to:  62 Changed 15 years ago by Steffen Pingel

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() 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', []]]

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 tickets new 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 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.

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 15 years ago by osimons

Updated patch - further fixes and improvements following research and suggestions.

comment:64 Changed 15 years ago by osimons

Thanks for testing and feedback.

I've attached an updated patch that futher improves things:

  1. 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.
  2. update() now has TICKET_VIEW as lowest possible permission. In reality, either TICKET_CHGPROP or TICKET_APPEND is needed depending on what update contains. May throw permission errors on validation, but that is to be expected anyway. See #3642.
  3. 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.
  4. 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.
  5. 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 15 years ago by Steffen Pingel

Added label and hint and increased version to 1.1.0

Changed 15 years ago by Steffen Pingel

renamed TicketStatusRPC back to StatusRPC and updated documentation for getActions()

comment:65 in reply to:  64 ; Changed 15 years ago by Steffen Pingel

  1. 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.

  1. 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.

  1. 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 in reply to:  65 Changed 15 years ago by Steffen Pingel

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 15 years ago by osimons

Last one :-) Minor tweaks.

comment:67 Changed 15 years ago by osimons

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 15 years ago by osimons

(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 to TICKET_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 15 years ago by osimons

Resolution: fixed
Status: newclosed

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 15 years ago by Steffen Pingel

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.