Problem with customfield when quick create or bulk update

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Currently running RT 3.4.2 with perl 5.8.4-8 and apache 2.0.53-5 on a
Debian box. I seem to have a small problem with QuickCreate and Bulk
Update. Same problem existed with RT 3.4.1.

I have one globally defined custom field, “CustomerId”. This seems to
work, except in two specific situations: 1) in quick create where it
doesn’t matter if and what value I enter in the custom field and 2) in
bulk ticket update if i do not enter a value. In both cases I end up
with a null value in the CF. When I edit the newly created ticket, via
“Basics” tab, I can specify a CustomerId which is then recorded.

Any one knows what my problem is?


Rejo Zenger rejo@rz.xs4all.nl - http://rejo.zenger.nl - PGP 0x75FC50F3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFClW0WHa9Q5nX8UPMRArUmAJ4uALVn1nFVA26B0R+eOJwZ4hy0pQCfY1u5
NhZsMJO+pe18dAiDGtDCSfM=
=e5pp
-----END PGP SIGNATURE-----

Hi,

Currently running RT 3.4.2 with perl 5.8.4-8 and apache 2.0.53-5 on a
Debian box. I seem to have a small problem with QuickCreate and Bulk
Update. Same problem existed with RT 3.4.1.

Last I looked, QuickCreate doesn’t deal with custom fields. (Or really
anything other than reminder-level stuff). Is Bulk Update resetting
valid fields?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jesse (and others),

++ 26/05/05 02:36 -0400 - Jesse Vincent:

Currently running RT 3.4.2 with perl 5.8.4-8 and apache 2.0.53-5 on a
Debian box. I seem to have a small problem with QuickCreate and Bulk
Update. Same problem existed with RT 3.4.1.

Last I looked, QuickCreate doesn’t deal with custom fields. (Or really
anything other than reminder-level stuff). Is Bulk Update resetting
valid fields?

If QuickCreate does not deal with custom fields, then I don’t understand
why I see the field in the QC form. The field is located just beneath
the Subject field and before the Attach File field. Shouldn’t it be
there? [1]

As for Bulk Update, it does reset valid field values. Say, I have a
couple of tickets listed, some of them with no value and some of them
with some value (not specifically the same). These values will get:

  1. resetted to a null value, regardless a value existed or not, if I
    have not specified a value in the CF or
  2. set to the new value if I have specified one in the CF.

Does this help?

[1] I guess this is because the QuickCreate calls Ticket/Create.html
which has these fields defined roughly after linenumber 115.


Rejo Zenger rejo@rz.xs4all.nl - http://rejo.zenger.nl - PGP 0x75FC50F3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFClYtiHa9Q5nX8UPMRAlMgAKDUl59FyGlg85a2iSFEkJdIX8se2QCbB7cz
JD87AKjPc1+5uU6PAdLYZv8=
=LFUK
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

++ 26/05/05 10:40 +0200 - Rejo Zenger:

Hi Jesse (and others),

++ 26/05/05 02:36 -0400 - Jesse Vincent:

Currently running RT 3.4.2 with perl 5.8.4-8 and apache 2.0.53-5 on a
Debian box. I seem to have a small problem with QuickCreate and Bulk
Update. Same problem existed with RT 3.4.1.

Last I looked, QuickCreate doesn’t deal with custom fields. (Or really
anything other than reminder-level stuff). Is Bulk Update resetting
valid fields?
[…]
As for Bulk Update, it does reset valid field values. Say, I have a
couple of tickets listed, some of them with no value and some of them
with some value (not specifically the same). These values will get:

  1. resetted to a null value, regardless a value existed or not, if I
    have not specified a value in the CF or
  2. set to the new value if I have specified one in the CF.

Does this help?
[…]

Hi Jesse (and others),

Maybe I am showing patience too little, but do you think you can help me
on this problem? Currently, this is the only issue in RT we have and the
only reason why RT is not yet officially in production…


Rejo Zenger rejo@rz.xs4all.nl - http://rejo.zenger.nl - PGP 0x75FC50F3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFCmE2cHa9Q5nX8UPMRAigRAJ9KFN2nKSOKaHnUjrozcshuhjFn6wCgwE1X
2vD/Gh8vyEP3F2u8HzIEah8=
=pHek
-----END PGP SIGNATURE-----

As for Bulk Update, it does reset valid field values. Say, I have a
couple of tickets listed, some of them with no value and some of them
with some value (not specifically the same). These values will get:

  1. resetted to a null value, regardless a value existed or not, if I
    have not specified a value in the CF or
  2. set to the new value if I have specified one in the CF.

Does this help?
[…]

Hi Jesse (and others),

Maybe I am showing patience too little, but do you think you can help me
on this problem? Currently, this is the only issue in RT we have and the
only reason why RT is not yet officially in production…

Unfortunately, as a small company, we don’t have the resources to deal
with every issue reported by end-users as quickly as we do for customers
on support contracts. I really do wish we had the resources to be able
to give everybody free commercial-grade support. As I look at 3.4.2’s
Bulk Update page, I don’t see ticket custom fields at all. (They existed
in 3.4.1 but were quite buggy and got pulled. It is soemthing we’ve
implemented in the QUEBEC branch for 3.6 and I suspect it could be
backported without much trouble)

Jesse

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

++ 28/05/05 13:03 -0400 - Jesse Vincent:

Maybe I am showing patience too little, but do you think you can help me
on this problem? Currently, this is the only issue in RT we have and the
only reason why RT is not yet officially in production…

Unfortunately, as a small company, we don’t have the resources to deal
with every issue reported by end-users as quickly as we do for customers
on support contracts. I really do wish we had the resources to be able
[…]

Sure. No problem. As I said, I was most likely a bit too impatient for
an answer. It doesn’t matter if you are not able to help me solve this
bug - than I will simply go for a different (and probably less cleaner)
solution.

Bulk Update page, I don’t see ticket custom fields at all. (They existed
in 3.4.1 but were quite buggy and got pulled. It is soemthing we’ve
implemented in the QUEBEC branch for 3.6 and I suspect it could be
backported without much trouble)

I’m not sure (I’m not much of a coder), but I guess the following piece
from html/Search/Bulk.html is where the custom field is defined for the
bulk update page:

155 % while (my $CF = $TxnCFs->Next()) {
156 <TR>
157 <TD ALIGN=RIGHT><% $CF->Name %>:</TD>
158 <TD><& /Elements/EditCustomField, 
159     CustomField => $CF, 
160     NamePrefix => "Object-RT::Transaction--CustomField-"
161     &><em><% $CF->FriendlyType %></em></TD>
162 </TD></TR>
163 % } # end if while

I’m running:

ii request-tracke 3.4.2-4 Extensible trouble-ticket tracking system
ii rt3.4-clients 3.4.2-4 Mail gateway and command-line interface to r

If I can’t find a proper solution myself, I will simply remove them.


Rejo Zenger rejo@rz.xs4all.nl - http://rejo.zenger.nl - PGP 0x75FC50F3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFCmOdDHa9Q5nX8UPMRAnZRAJ0e/KPmjIrEixJjklaVrfiKbRi2SQCgyB5Z
Bv+biktAoV+jq60pw3bjh1M=
=UOdl
-----END PGP SIGNATURE-----