Opened 10 years ago

Closed 8 years ago

# 0.11 compatible version

Reported by: Owned by: Sven Odd Simon Simonsen normal XmlRpcPlugin normal martin.marcher@…, Felix Schwarz, jgoering@…, key@… 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...

### Changed 10 years ago by Emmanuel Blot

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

### comment:2 follow-up:  4 Changed 10 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:4 in reply to:  2 Changed 10 years ago by Emmanuel Blot

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

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

### comment:6 follow-up:  9 Changed 10 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 follow-up:  8 Changed 10 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 10 years ago by Emmanuel Blot

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 10 years ago by Emmanuel Blot

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 10 years ago by Emmanuel Blot

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

### comment:10 Changed 10 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 10 years ago by Steffen Pingel

Fix for get_changelog

### comment:11 Changed 10 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 10 years ago by ben@…

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

### comment:12 follow-up:  16 Changed 10 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 10 years ago by Steffen Pingel

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

### comment:14 follow-up:  17 Changed 10 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:16 in reply to:  12 Changed 10 years ago by anonymous

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:

### comment:22 follow-up:  23 Changed 10 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 ; follow-up:  24 Changed 10 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 10 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

Patch for 0.11

### Changed 10 years ago by mmay

Patch for 0.11, Mylyn is now working :-)

### comment:25 follow-up:  26 Changed 10 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 10 years ago by Rainer Sokoll

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 10 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 ; follow-ups:  29  30 Changed 10 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 ; follow-up:  31 Changed 10 years ago by Rainer Sokoll

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

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

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 10 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 follow-up:  33 Changed 10 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 10 years ago by martin.marcher@…

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 10 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 10 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 10 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?

fixes for trunk

### comment:37 follow-up:  38 Changed 10 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 10 years ago by anonymous

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 10 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 10 years ago by Rainer Sokoll

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 10 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 10 years ago by Alec Thomas

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

### Changed 10 years ago by Alec Thomas

Validate permissions and ticket data before updating/creating.

### comment:43 Changed 10 years ago by Alec Thomas

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 10 years ago by Felix Schwarz

Cc: Felix Schwarz added changed from Alec Thomas to Felix Schwarz new → assigned

### comment:45 Changed 10 years ago by Felix Schwarz

Owner: changed from Felix Schwarz to Alec Thomas assigned → new

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

### Changed 10 years ago by tweitzel@…

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

### comment:46 follow-up:  47 Changed 10 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 10 years ago by Rainer Sokoll

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:48 Changed 10 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 9 years ago by Mark Curtis

Patch that allows XMLRPC to execute an action

### comment:49 follow-up:  50 Changed 9 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 9 years ago by anonymous

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:52 follow-up:  53 Changed 9 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 9 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 9 years ago by anonymous

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 9 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 9 years ago by zefyrus@…

pach to allow_none marshal error

### comment:56 Changed 9 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:58 Changed 8 years ago by anonymous

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

Thanks

### comment:61 Changed 8 years ago by rupert thurner

#3110 that is ...

### Changed 8 years ago by Odd Simon Simonsen

Workflow support for xmlrpc plugin

### comment:62 follow-up:  63 Changed 8 years ago by Odd Simon Simonsen

Owner: changed from Alec Thomas to Odd Simon Simonsen

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

• 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 8 years ago by Odd Simon Simonsen

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

### comment:64 follow-up:  65 Changed 8 years ago by Odd Simon Simonsen

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

Added label and hint and increased version to 1.1.0

### Changed 8 years ago by Steffen Pingel

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

### comment:65 in reply to:  64 ; follow-up:  66 Changed 8 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 8 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 8 years ago by Odd Simon Simonsen

Last one :-) Minor tweaks.

### comment:67 Changed 8 years ago by Odd Simon Simonsen

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 8 years ago by Odd Simon Simonsen

(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 8 years ago by Odd Simon Simonsen

Resolution: → fixed 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 8 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