I'm working on automating my setup of RT queues and using rt(1) to do
so.  It seems there's no way (or at least no easily discoverable way) to
set and change the AdminCc for a queue, could that please be added?

severity 594982 wishlist
tags 594982 +upstream
thanks

I don't believe that this functionality is exposed by the REST
interface of RT itself, so that would have to be added before rt could
do it.

Either way, I'm fairly sure that this would be considered an enhancement
rather than defect by upstream (the REST interface doesn't really cover
administration, just day to day operation), so setting severity accordingly.

I will forward this upstream when I have a moment.

Thanks for the report.

Dominic.

]] Dominic Hargreaves

| severity 594982 wishlist
| tags 594982 +upstream
| thanks
|
| On Tue, Aug 31, 2010 at 10:20:33AM +0200, Tollef Fog Heen wrote:
| > I'm working on automating my setup of RT queues and using rt(1) to do
| > so.  It seems there's no way (or at least no easily discoverable way) to
| > set and change the AdminCc for a queue, could that please be added?
|
| I don't believe that this functionality is exposed by the REST
| interface of RT itself, so that would have to be added before rt could
| do it.

Ok.

| Either way, I'm fairly sure that this would be considered an enhancement
| rather than defect by upstream (the REST interface doesn't really cover
| administration, just day to day operation), so setting severity accordingly.

It would be really useful if all functionality in RT is exposed through
the REST interface.  I guess that might be a fairly significant effort,
though. :-)

Until then, it would be useful if the limitations are documented, and if
possible, what workarounds are available.

| I will forward this upstream when I have a moment.

Thanks a lot.

Regards,

Sure. Just for completeness here, then, before I have a chance to write
some documentation: The RT native perl API is pretty usable once you get
used to it, but unfortunately isn't that well documented. Have a browse
through the core code to get a feel for the object model and calling
API. It's actually on my todo list at work to automate queue creation in
a similar way :)

Obviously this only works if you are in a position to run code with the
same database access as the RT application server itself.

]] Dominic Hargreaves

| On Wed, Sep 01, 2010 at 07:47:50AM +0200, Tollef Fog Heen wrote:
| > ]] Dominic Hargreaves
|
| > | Either way, I'm fairly sure that this would be considered an enhancement
| > | rather than defect by upstream (the REST interface doesn't really cover
| > | administration, just day to day operation), so setting severity accordingly.
| >
| > It would be really useful if all functionality in RT is exposed through
| > the REST interface.  I guess that might be a fairly significant effort,
| > though. :-)
| >
| > Until then, it would be useful if the limitations are documented, and if
| > possible, what workarounds are available.
|
| Sure. Just for completeness here, then, before I have a chance to write
| some documentation: The RT native perl API is pretty usable once you get
| used to it, but unfortunately isn't that well documented. Have a browse
| through the core code to get a feel for the object model and calling
| API. It's actually on my todo list at work to automate queue creation in
| a similar way :)

I guess I could do it that way.

Another annoying thing is that rt(1) exits 0 even when operations fail,
leading me to have chef recipes that do:

  execute "create queue" do
    command "rt create -t queue set name='#{queue}' set CorrespondAddress=#{queue}@#{node[:domain]} set CommentAddress=#{queue}-comment@#{node[:domain]}"
    environment({ "RTCONFIG" => "/etc/request-tracker3.8/rt_root.conf" })
    not_if "rt show queue/#{queue} | grep -q '^Name: #{queue}$'", :environment => { "RTCONFIG" => "/etc/request-tracker3.8/rt_root.conf" }
  end

  execute "verify queue existence" do
    command "rt show queue/#{queue} | grep -q '^Name: #{queue}$'"
    environment({ "RTCONFIG" => "/etc/request-tracker3.8/rt_root.conf" })
  end

which is a bit silly.

Do you want a separate bug report for that?

| Obviously this only works if you are in a position to run code with the
| same database access as the RT application server itself.

In this case, I'm running stuff as root on the machine where RT is
installed, so that bit is easy enough.

Yeah, that's more definitely a (minor) bug.

Cheers,
Dominic.

Dear submitter,

as the package request-tracker4 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1134418

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)