Queue_Overlay::ValidateName in 3.2.2 vs 3.4.4

RT Developers
1

I’ve just upgraded my customized RT 3.2.2 to 3.4.4, and
there’s some sort of conflict with RT::Queue_Overlay::ValidateName.

After comparing the 3.2.2 version and the 3.4.4 version, it looks
like Queue_Overlay.pm is pretty much the same, with the following
change in sub ValidateName:

In 3.2.2:

if ( $tempqueue->Name() ) {

in 3.4.4:

if ( $tempqueue->Name() && $tempqueue->id != $self->id)  {

The new code gives me the following error:

error:		Can't use string ("RT::Queue") as a HASH ref while "strict
refs" in use at /usr/share/perl5/DBIx/SearchBuilder/Record.pm line 382.
context:	
...		
378:	*Id = \&id;
379:	
380:	sub id {
381:	my $pkey = $_[0]->_PrimaryKey();
382:	$_[0]->{'values'}->{$pkey};
383:	}
384:	
385:	# }}}
386:	
...		
code stack:		/usr/share/perl5/DBIx/SearchBuilder/Record.pm:382
/opt/rt3/lib/RT/Queue_Overlay.pm:458
/opt/rt3/local/html/Ticket/Elements/ShowSurveyTools:19
/opt/rt3/local/html/Ticket/Elements/ShowSummary:33
/opt/rt3/share/html/Ticket/Display.html:57
/opt/rt3/share/html/autohandler:215

BUT, reverting to the older code makes it go away.

What, then, is the significance of the '$tempqueue->id != $self->id)'
test? What problem was this designed to fix? How can I work around it?

Thanks,

Jens

2

I’ve just upgraded my customized RT 3.2.2 to 3.4.4, and
there’s some sort of conflict with RT::Queue_Overlay::ValidateName.

After comparing the 3.2.2 version and the 3.4.4 version, it looks
like Queue_Overlay.pm is pretty much the same, with the following
change in sub ValidateName:

Are you maybe somewhere calling ValidateName in Class context rather
than object context?

3

I’ve just upgraded my customized RT 3.2.2 to 3.4.4, and
there’s some sort of conflict with RT::Queue_Overlay::ValidateName.

After comparing the 3.2.2 version and the 3.4.4 version, it looks
like Queue_Overlay.pm is pretty much the same, with the following
change in sub ValidateName:

Are you maybe somewhere calling ValidateName in Class context rather
than object context?

Hi Jesse,

Yes. I am creating Queues on the fly, and checking that they haven’t
already been created before doing so. Like this:

if (RT::Queue->ValidateName("ws-$id"))
{
	#ValidateName says that's an OK name for a queue, which means it
	doesn't yet exist
	$new_queue_already_exists = 0;
}

What I’m doing is creating Queues named ‘ws-$id’ where $id is the TicketId
in a “master” queue. The ticket in the ‘master’ queue allows the user
to create the ‘secondary’ queue if desired.

Jens

4

Yes. I am creating Queues on the fly, and checking that they haven’t
already been created before doing so. Like this:

if (RT::Queue->ValidateName(“ws-$id”))
{

Nope. you can’t do that.

5

Yes. I am creating Queues on the fly, and checking that they haven’t
already been created before doing so. Like this:

if (RT::Queue->ValidateName("ws-$id"))
{

Nope. you can’t do that.

Hmmm… but it works in 3.2.2. And there appear to be lots of Class-based
method calls throughout the code. Why is this bad? I don’t understand.

Jens

6

already been created before doing so. Like this:

if (RT::Queue->ValidateName("ws-$id"))

Nope. you can’t do that.

Hmmm… but it works in 3.2.2. And there appear to be lots of Class-based
method calls throughout the code. Why is this bad? I don’t understand.

Because the validate methods are object methods, not class methods. It’s
sometimes important to be able to look at an object when validating one
of its attributes.

7

already been created before doing so. Like this:

if (RT::Queue->ValidateName("ws-$id"))

Nope. you can’t do that.

Hmmm… but it works in 3.2.2. And there appear to be lots of Class-based
method calls throughout the code. Why is this bad? I don’t understand.

Because the validate methods are object methods, not class methods. It’s
sometimes important to be able to look at an object when validating one
of its attributes.

OK. Then what is the appropriate way to validate a proposed queue name?
I don’t have the object until it’s created, and I want to validate it
before I create it. How do I escape this catch-22?

Thanks,

Jens

8

OK. Then what is the appropriate way to validate a proposed queue name?
I don’t have the object until it’s created, and I want to validate it
before I create it. How do I escape this catch-22?

You can create a queue object before you create a new queue record in
the database.

9

OK. Then what is the appropriate way to validate a proposed queue name?
I don’t have the object until it’s created, and I want to validate it
before I create it. How do I escape this catch-22?

You can create a queue object before you create a new queue record in
the database.

Yes. That works. Thanks!

Jens