[Rt-devel] [PATCH]: Ticket transaction querying in REST interfaceis not restrictive enough

Philip Kime pkime at Shopzilla.com
Mon Feb 12 21:54:59 EST 2007


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

________________________________

From: Dmitri Tikhonov [mailto:Dmitri.Tikhonov at vonage.com] 
Sent: Monday, February 12, 2007 6:34 PM
To: Philip Kime; rt-devel at 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.

-----Original Message-----
From: rt-devel-bounces at lists.bestpractical.com on behalf of Philip Kime
Sent: Mon 2/12/2007 6:04 PM
To: rt-devel at lists.bestpractical.com
Subject: [Rt-devel] [PATCH]: Ticket transaction querying in REST
interfaceis not restrictive enough

Against 3.6.3 to file

<rtpath>/share/html/REST/1.0/Forms/ticket/history

This patch fixes the following issue:

rt show ticket/N/history/id/M

succeeds where transaction M has nothing to do with ticket N. Put
another way, transaction queries always succeed if the transation number
is valid.

PK

--
Philip Kime
NOPS Systems Architect
310 401 0407




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bestpractical.com/pipermail/rt-devel/attachments/20070212/b4c6e666/attachment-0001.htm


More information about the Rt-devel mailing list