owner will be unset on ticket.update

[Hinnack]

I am using api 1.2 on trac 0.11. I try to use ticket.update with a new action - but regardless if I set owner or not it is deleted!

[osimons]

It sounds very much like a unit test is needed to test this, and it would be helpful if you could provide me with your example data and calls. Could you please provide some more information about the 'action' states, what data ticket contains and what data is needed in update() to reproduce this?

[Hinnack]

hmm, I thought I clould change the owner by the name owner as earlier... can you please add action_leave_reassign_owner and action_resolve_resolve_resolution to the documentation?

[osimons]

No, I can't really add to documentation either as you need to call ticket.getActions(ticket_id) to discover what actions are available depending on trac.ini workflow configuration and user permissions. Different workflows will use different actions and rules, see ​trac:wiki:TracWorkflow

[anonymous]

I know and do this - old style still. I thought I could set the owner of a ticket by passing owner=xyz in the struct. this does not work anymore.
neither in ticket.getActions nor in ticket.update this is stated. nowhere on the whole docu page I can find action_leave_reassign_owner and action_resolve_resolve_resolution
by docu-page I mean doing a GET on the /login/xmlrpc url of my trac installation...

[osimons]

Replying to anonymous:

I know and do this - old style still.

You can't pick and mix, so don't add action unless you on client-side supports retrieving actions (ticket.getActions) and supplying a valid action along with your update.

Oh, and your 'old-style' behavior will disappear soon as with Workflow being a core feature of Ticket Sytem from 0.11, just updating fields without going through manipulator or workflow plugins is likely to harm the state of your tickets compared to the flow that web updates implements.

Seeing 'action' is in itself a pluggable workflow system, where all depends on a) what you have installed and b) how you have configured it, and c) the permissions of the user, and d) the current state of the ticket, e) ++, I cannot document the possible options directly in HTML documentation.

See ​trac:wiki:TracWorkflow, ​trac:wiki:WorkFlow/Examples and AdvancedTicketWorkflowPlugin as background on the 'action' field. However, to hide all this complexity I've made ticket.getActions() to allow you to retrieve the valid possible actions for this ticket based on current context.

You need to retrieve actions and use the appropriate action depending on what you want to do - it really works just like the Trac ticket form: You need to pick one action always (even if it is just 'leave').