I agree - if you’re going to query just transactions, do it directly.
But if you are doing it via a ticket, make sure that the transaction is
something to do with the ticket. If not, you can get confused because
you might query
rt show ticket/N/history/id/M
and because you get a result, you might assume that transaction M was
something to do with ticket N. After all the “history” part of the query
strongly suggests that the transaction is part of the ticket’s history.
I think this should be prevented and a plain transaction query interface
provided instead, if desirable (though it’s hard to see when you’d have
a transaction ID you wanted to know about and not know what ticket it
referred to …)
PKFrom: Dmitri Tikhonov [mailto:Dmitri.Tikhonov@vonage.com]
Sent: Monday, February 12, 2007 6:34 PM
To: Philip Kime; rt-devel@lists.bestpractical.com
Subject: RE: [Rt-devel] [PATCH]: Ticket transaction querying in REST
interfaceis not restrictive enough
I have noticed this behavior before and maybe it’s not useless:
What is someone wants to get just at the transaction itself?
As for restrictions, checking the ticket’s permissions should verify
whether the user can see it. I would like to see an interface like
this:
/REST/1.0/transaction/N
Just my $.02
- Dmitri.