Hi again,
Usual disclaimers, i could have barked up a wrong tree or something but…
It seems the RT CLI program, when it compiles the form parameters for
posting to RT has two paths, one with an existing form, one without.
The one without naturally only does ‘set’ operations (since there is no
server side add/del, only set, the CLI must return the complete list not
just the mods). However if you specify a command line add/del that is
’sufficient’ not to require editing, then this path is taken and the
add/del is silently ignored.
My patch checkes earlier on in the code to see if add/del contain
values, and if so enforces the download of the form from the server, the
other path for doing creating the post is used, which supports add and
del as well as set. This has no side effects on the process (doesn’t
cause edit or anything), well ok it makes it a touch slower, and makes
it work as it should. Usual caveats about the RT command line help
syntax being out of date, supported modes appear to be 'add
’ etc or ‘set attribute+=value’. There has
been a previous (contrib?) patch on this forum to fix some other bugs in
the documentation, this might be one of them.
Oh, the thing that should read /etc/rf.conf breaks real bad for me, so
i’m using java’s environment control instead, could be something wierd
in my setup perhaps?
Modification of a read-only value attempted at /opt/rt3/bin/rt line 1100.
1094-
1095-# Makes a hash of the specified configuration file.
1096-sub parse_config_file {
1097- my %cfg;
1098- my ($file) = @_;
1099: open (CFG, $file) && do {
1100: while () {
1101- chomp;
1102- next if (/^#/ || /^\s*$/);
1103-
1104- if (/^(user|passwd|server)\s+([^ ]+)$/) {
1105- $cfg{$1} = $2;
What i dont like is i have no idea why that happens 
looks like a
slightly more ‘perl-fluent’ version of code i’ve written a thousand
times before but i’ve not investigated too much, after jumbling the
syntax a little and still getting nowhere i gave up and moved to
environment variables so i dont really have anything useful to say
Oh final whine, i think my mysql cache is nasty and gets dirty, its not
invalidated on writes to the tables or something, i’ve seen select
statements pull up data i know is old, then miraculously a second later
the same query gives different (correct) results 
So much for locking
the table to ensure everyone is in sync heh. No doubt i need another
upgrade or something,
Iain
*** /tmp/rt 2003-10-15 15:15:31.000000000 +0100
— /opt/rt3/bin/rt 2003-10-15 15:18:12.000000000 +0100
*************** sub edit {
*** 271,276 ****
— 271,277 ----
%set = %add = %del = ();
my $slurped = 0;
my $bad = 0;
-
my $forceformget = 0; while (@ARGV) { $_ = shift @ARGV;
*************** sub edit {
*** 363,373 ****
# user doesn’t want to edit the form by hand, and the command line
# specifies only simple variable assignments.
if ($input) {
local $/ = undef;
$text = <STDIN>;
}
! elsif ($edit || !$cl) {
my $r = submit("$REST/show", { id => @objects, format => ‘l’ });
$text = $r->content;
}
— 364,379 ----
# user doesn’t want to edit the form by hand, and the command line
# specifies only simple variable assignments.
-
if (defined(%add) or defined(%del)) -
{ -
#IJP 15/08/2003 : if we are adding or deleting values from
the form then we better get a copy of it from the server, regardless of
command line parameters etc
-
$forceformget=1; -
} if ($input) { local $/ = undef; $text = <STDIN>; }
! elsif ($edit || !$cl || $forceformget) {
my $r = submit("$REST/show", { id => @objects, format => ‘l’ });
$text = $r->content;
}