Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8665 closed defect (worksforme)

owner will be unset on ticket.update

Reported by: Hinnack Owned by: osimons
Priority: normal Component: XmlRpcPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11


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!

Attachments (0)

Change History (5)

comment:1 Changed 7 years ago by 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?

comment:2 Changed 7 years ago by Hinnack

Resolution: worksforme
Status: newclosed

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?

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

comment:4 Changed 7 years ago by 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...

comment:5 in reply to:  4 Changed 7 years ago by 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').

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain osimons.
The resolution will be deleted.

Add Comment

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

Note: See TracTickets for help on using tickets.