EditCustomFieldsOnUpdate does not work anymore

RT Users
1

Hi,

looks like the callback based solution described here

http://wiki.bestpractical.com/index.cgi?EditCustomFieldsOnUpdate

does not work anymore. The custom fields are displayed correctly on Update.html. If I change values and do not put anything in the correspondence/comments field, press save changes, all custom field changes are processed without problems. If I however enter text in the correspondence field and then save changes all that happens is “message recorded” and the custom field values stay untouched.

Any ideas?

Kind regards,
JP

2

Hi,

looks like the callback based solution described here

Request Tracker Wiki

does not work anymore. The custom fields are displayed correctly on Update.html. If I change values and do not put anything in the correspondence/comments field, press save changes, all custom field changes are processed without problems. If I however enter text in the correspondence field and then save changes all that happens is “message recorded” and the custom field values stay untouched.

Any ideas?

I found the problem. At the bottom of Display.html a redirect
was added before the callback that EditCustomFieldsOnUpdate
is trying to use to update the CFs. If the callback was moved
above the preceeding if statement things should start working.

The callback also needs @Actions passed to it so that the CF
updates can be recorded.

-Todd

3

I found the problem. At the bottom of Display.html a redirect was
added before the callback that EditCustomFieldsOnUpdate is trying to
use to update the CFs. If the callback was moved above the preceeding
if statement things should start working.

You are my hero of the day. Thanks!

The callback also needs @Actions passed to it so that the CF updates
can be recorded.

That part I honestly do not fully understand. Would you happen to have a
patch?

Kind regards,
JP

4

I found the problem. At the bottom of Display.html a redirect was
added before the callback that EditCustomFieldsOnUpdate is trying to
use to update the CFs. If the callback was moved above the preceeding
if statement things should start working.

You are my hero of the day. Thanks!

The callback also needs @Actions passed to it so that the CF updates
can be recorded.

That part I honestly do not fully understand. Would you happen to have a
patch?

In Display.html add “Actions => @Action” to
the callback arguments. In the callback itself
add line “push @{$ARGS{Actions}}, @cf_results;”.

5

In Display.html add “Actions => @Action” to the callback arguments.
In the callback itself add line “push @{$ARGS{Actions}},
@cf_results;”.

This causes a loop here. At the bottom of Display.html

if (@Actions)

is true even though @Actions is empty.

if (scalar(@Actions) == 0) {

on the other hand works as expected. Strange. Moreover the actions are not displayed at the top of the Display.html result anymore even though the changes are submitted. We will debug this further tomorrow but maybe you have an idea?

Regards,
JP

6

In Display.html add “Actions => @Action” to
the callback arguments. In the callback itself
add line “push @{$ARGS{Actions}}, @cf_results;”.

Per our offline discussion:

  • Added ACtions => @Actions (plural) to Display.html
  • Added the line above to the Callback

I get the same behavior as previous to the changes:

  • Changes to CF with no Reply “take”
  • Changes to CF when accompanied with a Reply “don’t take”

-jd

7

In Display.html add “Actions => @Action” to
the callback arguments. In the callback itself
add line “push @{$ARGS{Actions}}, @cf_results;”.

Per our offline discussion:

  • Added ACtions => @Actions (plural) to Display.html
  • Added the line above to the Callback

I get the same behavior as previous to the changes:

  • Changes to CF with no Reply “take”
  • Changes to CF when accompanied with a Reply “don’t take”

I updated the rt/local/html/Callbacks/CustomFields/Ticket/Display.html/BeforeDisplay on the wiki.

Make sure you move the callback above the preceeding if statement.

Restart apache and flush the mason cache.

-Todd

8

Attached is my diff for Display.html. It should allow
the callback to start working again.

-Todd

display_callback_fix.diff (887 Bytes)

9

I updated the
rt/local/html/Callbacks/CustomFields/Ticket/Display.html/BeforeDisplay
on the wiki.

I am not sure this will work. ProcessObjectCustomFieldUpdates seems to return an array with an empty element even if it did not change anything. The following if therefore always redirects to Display.html causing a loop. This is very reproducable here with Perl 5.8.7 on FreeBSD. What did help was this:

<%init>
my $ARGSRef = $ARGS{‘ARGSRef’};
if ($$ARGSRef{‘id’} ne ‘new’){
my $Ticket = LoadTicket($$ARGSRef{‘id’});
my @cf_results = ProcessObjectCustomFieldUpdates(ARGSRef => $ARGSRef);
delete $cf_results[0] if ((scalar(@cf_results) == 1) && ($cf_results[0] eq ‘’));
push @{$ARGS{Actions}}, @cf_results;
}
</%init>

With this change everything works like a charm here (of course after putting the Callback in front of the if in Display.html which should be noted in the wiki as well btw. What is

<%args>
$Actions =>
</%args>

doing exactly? Things work without it as well. Moreover: Will someone talk/write to Jesse about the change in Display.html? This should be patched into rt.

Kind regards,
JP

10

JP, Todd, rt-users–

Yes, this works for us as well.

Perhaps this is an unintended side effect (or perhaps it’s by design), but
the only problem I’ve found with this approach is that Custom Field
changes don’t get mentioned at the top. I get “Message recorded” or
“Status changed to xxx”, but I don’t see the CF changes even though they
are made.

For the time being, I can deal with not getting confirmation of CF changes
as long as they are actually made, and with the Callback change made
below (combined with the move of the Callback) they do. And for that, I
thank you both.

-jdOn Wed, 26 Jul 2006, Koopmann, Jan-Peter wrote:

On Tuesday, July 25, 2006 9:12 PM Todd Chapman wrote:

I updated the
rt/local/html/Callbacks/CustomFields/Ticket/Display.html/BeforeDisplay
on the wiki.

I am not sure this will work. ProcessObjectCustomFieldUpdates seems to return an array with an empty element even if it did not change anything. The following if therefore always redirects to Display.html causing a loop. This is very reproducable here with Perl 5.8.7 on FreeBSD. What did help was this:

<%init>
my $ARGSRef = $ARGS{‘ARGSRef’};
if ($$ARGSRef{‘id’} ne ‘new’){
my $Ticket = LoadTicket($$ARGSRef{‘id’});
my @cf_results = ProcessObjectCustomFieldUpdates(ARGSRef => $ARGSRef);
delete $cf_results[0] if ((scalar(@cf_results) == 1) && ($cf_results[0] eq ‘’));
push @{$ARGS{Actions}}, @cf_results;
}
</%init>

With this change everything works like a charm here (of course after putting the Callback in front of the if in Display.html which should be noted in the wiki as well btw. What is

<%args>
$Actions =>
</%args>

doing exactly? Things work without it as well. Moreover: Will someone talk/write to Jesse about the change in Display.html? This should be patched into rt.

Kind regards,
JP

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions

11

Perhaps this is an unintended side effect (or perhaps it’s by
design), but the only problem I’ve found with this approach is that
Custom Field changes don’t get mentioned at the top. I get “Message
recorded” or “Status changed to xxx”, but I don’t see the CF changes
even though they are made.

That is strange. With 3.6.0 and after these changes this works for us for the first time. All changes on the update page seem to be recorded at the top of the resulting Display.html and all changes show in the following section. Let’s compare one more time. My setup currently:

BeforeDisplay:
<%init>
my $ARGSRef = $ARGS{‘ARGSRef’};
if ($$ARGSRef{‘id’} ne ‘new’){
my $Ticket = LoadTicket($$ARGSRef{‘id’});
my @cf_results = ProcessObjectCustomFieldUpdates(ARGSRef => $ARGSRef);
my @dresults = ProcessTicketDates( TicketObj => $Ticket, ARGSRef => $ARGSRef);

    delete $cf_results[0] if ((scalar(@cf_results) == 1) && ($cf_results[0] eq ''));
    push @{$ARGS{Actions}}, @cf_results, @dresults;

}
</%init>

<%args>
$Actions =>
</%args>

BeforeMessageBox:
<%init>
my $Ticket = LoadTicket($ARGS{‘id’});
</%init>
<& /Ticket/Elements/EditCustomFields, TicketObj => $Ticket &>
<& /Ticket/Elements/EditDueDate, TicketObj => $ Ticket &>
<& /Ticket/Elements/EditPriority, TicketObj => $ Ticket &>

Bottom of Display.html (the part that Jesse should change):

This code does automatic redirection if any updates happen.

It doesn’t work for the client.

$m->comp(‘/Elements/Callback’, _CallbackName => ‘BeforeDisplay’,
TicketObj => $TicketObj, Tickets => $Tickets, ARGSRef => %ARGS, Actions => @Actions );

if (@Actions) {
# We’ve done something, so we need to clear the decks to avoid
# resubmission on refresh.
# But we need to store Actions somewhere too, so we don’t lose them.
$session{“Actions”} = @Actions;
$m->redirect($RT::WebURL.“Ticket/Display.html?id=”.$TicketObj->id);
} else {
@Actions = @{$session{“Actions”} || };
delete $session{“Actions”};
}

Please note that in addition to CustomFields we also let the user change priority and due dates on the update page. Works like a charm.

Jason, can you confirm that you are running a similar setup with 3.6.x?

Kind regards,
JP

12

JP, Todd, rt-users–

If modified exactly as listed below, this works completely along with
proper notifications from RT.

I dropped the @Actions piece in the Callback (and perhaps over-improvised
by also removing it from Display.html) based on the comment that you made
(JP) that it was unnecessary. Re-adding it and doing it exactly as you
below works fine on my RT3.6.HEAD+Display.html-modification setup.

Sorry for the confusion, I over-improvised.

-jdOn Wed, 26 Jul 2006, Koopmann, Jan-Peter wrote:

On Wednesday, July 26, 2006 1:02 PM Jason A. Diegmueller wrote:

Perhaps this is an unintended side effect (or perhaps it’s by
design), but the only problem I’ve found with this approach is that
Custom Field changes don’t get mentioned at the top. I get “Message
recorded” or “Status changed to xxx”, but I don’t see the CF changes
even though they are made.

That is strange. With 3.6.0 and after these changes this works for us for the first time. All changes on the update page seem to be recorded at the top of the resulting Display.html and all changes show in the following section. Let’s compare one more time. My setup currently:

BeforeDisplay:
<%init>
my $ARGSRef = $ARGS{‘ARGSRef’};
if ($$ARGSRef{‘id’} ne ‘new’){
my $Ticket = LoadTicket($$ARGSRef{‘id’});
my @cf_results = ProcessObjectCustomFieldUpdates(ARGSRef => $ARGSRef);
my @dresults = ProcessTicketDates( TicketObj => $Ticket, ARGSRef => $ARGSRef);

   delete $cf_results[0] if ((scalar(@cf_results) == 1) && ($cf_results[0] eq ''));
   push @{$ARGS{Actions}}, @cf_results, @dresults;

}
</%init>

<%args>
$Actions =>
</%args>

BeforeMessageBox:
<%init>
my $Ticket = LoadTicket($ARGS{‘id’});
</%init>
<& /Ticket/Elements/EditCustomFields, TicketObj => $Ticket &>
<& /Ticket/Elements/EditDueDate, TicketObj => $ Ticket &>
<& /Ticket/Elements/EditPriority, TicketObj => $ Ticket &>

Bottom of Display.html (the part that Jesse should change):

This code does automatic redirection if any updates happen.

It doesn’t work for the client.

$m->comp(‘/Elements/Callback’, _CallbackName => ‘BeforeDisplay’,
TicketObj => $TicketObj, Tickets => $Tickets, ARGSRef => %ARGS, Actions => @Actions );

if (@Actions) {

We’ve done something, so we need to clear the decks to avoid

resubmission on refresh.

But we need to store Actions somewhere too, so we don’t lose them.

$session{“Actions”} = @Actions;
$m->redirect($RT::WebURL.“Ticket/Display.html?id=”.$TicketObj->id);
} else {
@Actions = @{$session{“Actions”} || };
delete $session{“Actions”};
}

Please note that in addition to CustomFields we also let the user change priority and due dates on the update page. Works like a charm.

Jason, can you confirm that you are running a similar setup with 3.6.x?

Kind regards,
JP

13

JP, Todd, rt-users–

If modified exactly as listed below, this works completely along with
proper notifications from RT.

Wounderful. I just changed the wiki page to reflect our findings. I will also try to reach Jesse in order to patch Display.html permanently.

Kind regards,
JP