ColumnMap/Once no longer behaving consistently after upgrade from 5.0.1 to 5.0.2

After an update from 5.0.1 to 5.0.2, our customisations are sometimes rendered. We add a badge-pill to the status to make it standout more and since the update, testing has shown that sometimes the Once file is used and sometimes it isnt.

It appears as if there is some sort of race condition/event happening where Once is sometimes processed and sometimes it is not.

local/html/Callbacks/OurApp/Elements/RT__Ticket/ColumnMap/Once:

<%INIT>

sub StatusInColour {

  my $Ticket = shift;
  my $status = $Ticket->Status;
  my $badge = undef;

  $badge = "badge-light";
  if (not defined($status)) {
    $status = "Not Set";
    $badge = "dark-light";
  }

  if ($status eq 'new') {
    $badge = "badge-info";
  } elsif ($status eq 'open') {
    $badge = "badge-warning";
  } elsif ($status eq 'resolved') {
    $badge = "badge-success";
  } elsif ($status eq 'rejected') {
    $badge = "badge-dark";
  } elsif ($status eq 'stalled') {
    $badge = "badge-secondary";
  }


  if ($badge) {
    $status = "<span class=\"badge badge-pill $badge\" style=\"font-size: calc(100% + 1px);\">$status</span>";
  }

  return \"<b>$status</b>";

}

$COLUMN_MAP->{Status}->{value} = \&StatusInColour;
</%INIT>
<%ARGS>
$COLUMN_MAP => undef
</%ARGS>

Has anyone else experienced this?

The “<%Once%>” block in mason is only called once, and looking in the code I see:

=item CallbackOnce

By default is false, otherwise runs callbacks only once per
process of the server. Such callbacks can be used to fill
structures.

Which is also used for this callback, so it makes sense that sometimes you don’t see this code run. I’d expect every process to have the callback though

Indeed - on 5.0.1 all is well. I couldn’t see this in the changelog but did see that Status ColumnMap was updated. Maybe the Once has been fixed afterall.

I value and respect your opinion.

hello,

can you tell me how you solved the problem please? I have the same behavior.

thank you

Hello all,

I had the same problem. It seems to have had something to do with the Mason cache handling. However, the error seems to have been fixed in the new RT 5.0.3 release. After the update to 5.0.3, the error no longer occurred.

Correct, this issue should be fixed in RT 5.0.3. The bug was also the cause of the broken RTIR links we mentioned in the notes.

Awesome! I’ll check and come back if it still misbehaving