0.11 compatible version

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

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

See also ticket:4280 for the setuptools issue.

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

Replying to eblot:

See also ticket:4280 for the setuptools issue.

I get this exact error too. Goes away when I remove the egg

I get the following error when I try to run a query:

'from_string() takes exactly 4 arguments (3 given)' while executing 'ticket.query()'

And this error when I try to fetch a ticket:

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

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.

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.

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

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

Fix for get_changelog

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.

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

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.

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

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'

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)

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]>

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.

The MyLyn? bug URL is https://bugs.eclipse.org/bugs/show_bug.cgi?id=175211

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.

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

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

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?

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

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

Patch for 0.11

Patch for 0.11, Mylyn is now working :-)

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

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!

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.

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.

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

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.

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?

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.

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?

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

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'

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?

fixes for trunk

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.

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)

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 .

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.

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 :).

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

Validate permissions and ticket data before updating/creating.

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.

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

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

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 ;-).

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.

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

Patch that allows XMLRPC to execute an action

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.

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.

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.

Works too for me with Trac 0.11, eclipse 3.3.2, Mylyn Trac Connector 2.3.0v20080225 and XMLRPC from trunk.

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?

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.

pach to allow_none marshal error

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

Just wondering if there is going to be a formal release of the plugin for trac 0.11.

Thanks

see here: http://sourceforge.net/tracker/index.php?func=detail&aid=2672182&group_id=1&atid=350001 for the version used on sourceforge.

see also #3310

#3110 that is ...

Workflow support for xmlrpc plugin

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?

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.

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

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

Added label and hint and increased version to 1.1.0

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

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.

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.

Last one :-) Minor tweaks.

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!

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

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.

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