Dear fellow RTers,
Looking at html/REST/1.0/Forms/ticket/attachments, I realized that one
does not really need to pass the ticket id in order to see a particular
attachment. As it stands right now, however, this is enforced by the
implementation. Let’s look at an example run of ‘rt’ utility
(attached). Since RT::Attachment is an object in its own right, why
not allow it to be accessed as such? Furthermore, ticket-loading code
at the top of html/REST/1.0/Forms/ticket/attachments does not do
anything useful, because it does not check whether a specific
attachment is actually associated with the ticket.
Attached patch moves ticket-loading code to the place where it’s
needed, so one can access any attachment using rt tool by saying
rt show ticket/0/attachments/6
To take things even further, why shouldn’t there be
html/REST/1.0/Forms/attachment? Then we could say things like
rt show attachment/6
Rationale: as I am writing RT::Client::REST, I am trying to make a
uniform framework for creating, editing, and retrieving of any
REST-supported RT object. Attachments, by being unnecessarily (IMO)
tagged onto ticket, don’t fit into my paradigm (you may call it a
fantasy world, though :).
Questions:
- What do you think? Agree/disagree?
- If the answer to (1) is agree, will you accept a patch?
Thank you,
P.S. RT::Client::REST 0.12 is now up on CPAN. While docs are still
pretty scarce, you can see where I am going with it.
sample-rt-run.txt (1.02 KB)
rt-rest-attachment.patch.txt (1.03 KB)
Dear fellow RTers,
Looking at html/REST/1.0/Forms/ticket/attachments, I realized that one
does not really need to pass the ticket id in order to see a particular
attachment. As it stands right now, however, this is enforced by the
implementation. Let’s look at an example run of ‘rt’ utility
(attached). Since RT::Attachment is an object in its own right, why
not allow it to be accessed as such? Furthermore, ticket-loading code
at the top of html/REST/1.0/Forms/ticket/attachments does not do
anything useful, because it does not check whether a specific
attachment is actually associated with the ticket.
I believe that this was an attempt at “Security” back around RT 3.0, in
a perhaps flawed attempt to stop people from brute-force iterating over
attachments to find things.
Attached patch moves ticket-loading code to the place where it’s
needed, so one can access any attachment using rt tool by saying
rt show ticket/0/attachments/6
This scares me a bit.
To take things even further, why shouldn’t there be
html/REST/1.0/Forms/attachment? Then we could say things like
rt show attachment/6
This doesn’t scare me. I’ll take a patch for it 
To take things even further, why shouldn’t there be
html/REST/1.0/Forms/attachment? Then we could say things like
rt show attachment/6
This doesn’t scare me. I’ll take a patch for it
I have a patch to do this and also
rt show attachment/6/content
- I’ll submit it shortly. It puts a warning message in place of the
content if it’s not text. I’d like to be able to “edit” attachments too
so that they can be added/modified from the command-line. Looking into
it.
PK
rt show attachment/6/content
- I’ll submit it shortly. It puts a warning message in place of the
content if it’s not text.
That would stop me from being able to download binary attachments.
I’d like to be able to “edit” attachments too
so that they can be added/modified from the command-line. Looking into
it.
I’d like to humbly request that you submit that as a separate patch, as
I’m not comfortable adding history-modifiying tools like that to RT.
That would stop me from being able to download binary attachments.
Don’t think so:
rt show attachment/6/content > file.doc
This is how I have it working at the moment.
I’d like to humbly request that you submit that as a separate patch,
as I’m not
comfortable adding history-modifiying tools like that to RT.
Me neither. It’s just I wanted to be able to attach things to tickets
without having to do it via the “comment” command as this sends mail.
Altering attachments is too dangerous, I agree. Changing the attachment
or adding them should be logged in the history as usual. Maybe an
“attach” command for tickets is the way to go - like comment but without
actually commenting?
as I’m not
comfortable adding history-modifiying tools like that to RT.
Me neither. It’s just I wanted to be able to attach things to tickets
without having to do it via the “comment” command as this sends mail.
Altering attachments is too dangerous, I agree. Changing the attachment
or adding them should be logged in the history as usual. Maybe an
“attach” command for tickets is the way to go - like comment but without
actually commenting?
Does it not actually create a correspond or comment transaction?
Actually, on further investigation, it seems that there is no public API
call to add attachments to a ticket - it’s done inside a ->comment or
->correspond. You can add attachments on ticket create but this isn’t
allowed in the REST API. I may look at addressing this so the “-a” flag
can be used on ticket creation?
PKFrom: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: 04 September 2006 17:08
To: Philip Kime
Cc: Jesse Vincent; rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] REST: should retrieving a particular attachment
require a ticket number?
as I’m not
comfortable adding history-modifiying tools like that to RT.
Me neither. It’s just I wanted to be able to attach things to tickets
without having to do it via the “comment” command as this sends mail.
Altering attachments is too dangerous, I agree. Changing the
attachment or adding them should be logged in the history as usual.
Maybe an “attach” command for tickets is the way to go - like comment
but without actually commenting?
Does it not actually create a correspond or comment transaction?
Actually, on further investigation, it seems that there is no public API
call to add attachments to a ticket - it’s done inside a ->comment or
->correspond. You can add attachments on ticket create but this isn’t
allowed in the REST API. I may look at addressing this so the “-a” flag
can be used on ticket creation?
Attachments are on transactions. (Create, Comment or Reply) making it
work on create from the cli sounds sane.
Yes, that’s what I realised after some code reading. I’ll make the REST
API understand the “-a” flag and submit a patch.
PKFrom: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: 04 September 2006 19:23
To: Philip Kime
Cc: Jesse Vincent; rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] REST: should retrieving a particular attachment
require a ticket number?
Actually, on further investigation, it seems that there is no public
API call to add attachments to a ticket - it’s done inside a ->comment
or
->correspond. You can add attachments on ticket create but this isn’t
allowed in the REST API. I may look at addressing this so the “-a”
flag can be used on ticket creation?
Attachments are on transactions. (Create, Comment or Reply) making it
work on create from the cli sounds sane.
PK
-----Original Message-----
From: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: 04 September 2006 17:08
To: Philip Kime
Cc: Jesse Vincent; rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] REST: should retrieving a particular
attachment require a ticket number?
as I’m not
comfortable adding history-modifiying tools like that to RT.
Me neither. It’s just I wanted to be able to attach things to
tickets without having to do it via the “comment” command as this
sends mail.
Altering attachments is too dangerous, I agree. Changing the
attachment or adding them should be logged in the history as usual.
Maybe an “attach” command for tickets is the way to go - like
comment but without actually commenting?
Does it not actually create a correspond or comment transaction?
–