360489 - Can't locate object method "type_name" via package "Bugzilla::Field" when listing custom fields

Status: RESOLVED FIXED

(Bugzilla :: Administration, task)

Description

[Frédéric Buclin]

For the same reason as in bug 357374, TT 2.15 throws the error:

undef error - Can't locate object method "type_name" via package "Bugzilla::Field" at /usr/lib/perl5/vendor_perl/5.8.8/i386-linux/Template/Stash.pm line 870.

This is due to the following code in admin/custom_fields/list.html.tmpl:

[%# We want to display the type name of fields, not their type ID. %]
[% FOREACH cf_field = custom_fields %]
  [% cf_field.type_name = field_types.${cf_field.type} %]
[% END %]

This must be fixed before we release 3.0 else custom fields won't be usable on Windows installations.

Comment 1

[Max Kanat-Alexander]

Okay, wait. We *explicitly* "use Template::Stash" in Bugzilla::Template. I think there's something we could do to make Template-Toolkit work properly.

We should be able to add a key to a hash, and not have it be interpreted as a nonexisted method. The fact that we can't seems like a serious error in TT or in our configuration of it.

Comment 2

[Frédéric Buclin]

No, the problem is that we really pass objects, and TT no longer falls back to a hash if it cannot find the expected method.

Comment 3

[Max Kanat-Alexander]

(In reply to comment #2)
> No, the problem is that we really pass objects, and TT no longer falls back to
> a hash if it cannot find the expected method.

  Objects ARE hashes. From perl's viewpoint, there's basically NO DIFFERENCE. So there should be no difference from the perspective of TT. We use objects as hashes all the time, in Bugzilla. We should be able to do so in TT as well.

  And why is this only a problem on Windows, then, if that's really what TT is supposed to be doing?

Comment 4

[Frédéric Buclin]

See bug 357374 comment 14. The problem is that TT now looks at:

    if ($rootref eq 'HASH' || $atroot) {

    elsif ($rootref eq 'ARRAY' && $item =~ /^-?\d+$/) {

    elsif (UNIVERSAL::isa($root, 'UNIVERSAL')) {

... and so will enter the HASH block instead of the last block.


Previously, it did (from what I can see):

#     eval { $result = $root->$item(@$args, $value); };     
# 
#     if ($@) {
#         die $@ if ref($@) || ($@ !~ /Can't locate object method/);
#
#         # failed to call object method, so try some fallbacks
#         if (UNIVERSAL::isa($root, 'HASH') && exists $root->{ $item }) {
#         $result = ($root->{ $item } = $value)
#             unless $default && $root->{ $item };
#         }


As you can see, it no longer "tries some fallbacks". It prefers to fail.

Comment 5

[Max Kanat-Alexander]

I think that's a bug in TT. Being able to set a hash value in perl and not in Template Toolkit doesn't make any sense.

TT 2.15 has done nothing but cause us problems, so far.

Comment 6

[Frédéric Buclin]

(In reply to comment #5)
> TT 2.15 has done nothing but cause us problems, so far.

Yeah, and MySQL 5.0.25+ and DBD::mysql 3.0003 - 3.0006, and what else? Fortunately Bugzilla is smarter. ;)

Comment 7

[Frédéric Buclin]

Attachment: patch, v1

This bug was much easier to fix than expected. :)

Comment 8

[Max Kanat-Alexander]

Comment on attachment 245511 [details] [diff] [review]
patch, v1

Okay, yeah, if that works, that's more sensible anyway.

Comment 9

[Frédéric Buclin]

Checking in template/en/default/admin/custom_fields/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/admin/custom_fields/list.html.tmpl,v  <--  list.html.tmpl
new revision: 1.3; previous revision: 1.2
done