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

RESOLVED FIXED in Bugzilla 3.0

Status

()

Bugzilla
Administration
--
major
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Frédéric Buclin, Assigned: Frédéric Buclin)

Tracking

2.23.3
Bugzilla 3.0
Bug Flags:
approval +
blocking3.0 +

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
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.
(Assignee)

Updated

12 years ago
Flags: blocking3.0?

Comment 1

12 years ago
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.
Flags: blocking3.0? → blocking3.0+
(Assignee)

Comment 2

12 years ago
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

12 years ago
(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?
(Assignee)

Comment 4

12 years ago
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

12 years ago
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.
(Assignee)

Comment 6

12 years ago
(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. ;)
(Assignee)

Updated

12 years ago
Assignee: administration → LpSolit
(Assignee)

Comment 7

12 years ago
Created attachment 245511 [details] [diff] [review]
patch, v1

This bug was much easier to fix than expected. :)
Attachment #245511 - Flags: review?(mkanat)

Comment 8

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

Okay, yeah, if that works, that's more sensible anyway.
Attachment #245511 - Flags: review?(mkanat) → review+
(Assignee)

Updated

12 years ago
Status: NEW → ASSIGNED
Flags: approval?
Flags: approval? → approval+
(Assignee)

Comment 9

12 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.