Hello,
I’m having what is likely a simple problem, but I haven’t been able to
come up with the answer on my own yet and was hoping for some advice.
What I’m trying to do is add keys to the %FIELDS and %dispatch hashes in
Tickets_Local in order to handle searches on a custom Tags table,
however the new keys are never properly added to the hashes. I’ve
attempted including them directly in the hash declarations:
%Fields =
…
Tag => [ ‘TAG’, ],
Tags => [ ‘TAG’, ],
%dispatch =
…
TAG => &_TagLimit,
As well as adding them in after the fact:
$FIELDS{‘Tag’} = [‘TAG’];
$FIELDS{‘Tags’} = [‘TAG’];
$dispatch{‘TAG’} = &_TagLimit;
Neither of which seems to have any affect on the hashes at runtime.
Both of the above work properly, however, when I add them directly into
Tickets_Overly.pm
My question is if anyone knows of a way to update these hashes without
modifying Tickets_Overlay (keep the update in Tickets_Local). I would
guess this is a problem of scope, but I haven’t yet been able to find a
way around it (including completely commenting out the FIELDS and
dispatch declarations in Tickets_Overlay).
Hello,
I’m having what is likely a simple problem, but I haven’t been able to
come up with the answer on my own yet and was hoping for some advice.
What I’m trying to do is add keys to the %FIELDS and %dispatch hashes in
Tickets_Local in order to handle searches on a custom Tags table,
however the new keys are never properly added to the hashes. I’ve
attempted including them directly in the hash declarations:
%Fields =
…
Tag => [ ‘TAG’, ],
Tags => [ ‘TAG’, ],
%dispatch =
…
TAG => &_TagLimit,
As well as adding them in after the fact:
$FIELDS{‘Tag’} = [‘TAG’];
$FIELDS{‘Tags’} = [‘TAG’];
$dispatch{‘TAG’} = &_TagLimit;
Neither of which seems to have any affect on the hashes at runtime.
Both of the above work properly, however, when I add them directly into
Tickets_Overly.pm
My question is if anyone knows of a way to update these hashes without
modifying Tickets_Overlay (keep the update in Tickets_Local). I would
guess this is a problem of scope, but I haven’t yet been able to find a
way around it (including completely commenting out the FIELDS and
dispatch declarations in Tickets_Overlay).
In your _Local file are you setting the package name?
Yes, I am setting the package name in Tickets_Local. I should mention
that all previous changes have worked fine in Tickets_Local and all the
other _Locals, but all those changes were to existing or new
subroutines, not hash definitions.
For example, the &_TagLimit routine mentioned below is read without any
problems, and it only exists in the _Local, not the _Overlay. It’s only
the hash definitions that I can’t seem to add to.
Thanks,
Michael
Todd Chapman wrote:> On Fri, Mar 03, 2006 at 01:12:14PM -0800, Michael Gilbert wrote:
Hello,
I’m having what is likely a simple problem, but I haven’t been able to
come up with the answer on my own yet and was hoping for some advice.
What I’m trying to do is add keys to the %FIELDS and %dispatch hashes in
Tickets_Local in order to handle searches on a custom Tags table,
however the new keys are never properly added to the hashes. I’ve
attempted including them directly in the hash declarations:
%Fields =
…
Tag => [ ‘TAG’, ],
Tags => [ ‘TAG’, ],
%dispatch =
…
TAG => &_TagLimit,
As well as adding them in after the fact:
$FIELDS{‘Tag’} = [‘TAG’];
$FIELDS{‘Tags’} = [‘TAG’];
$dispatch{‘TAG’} = &_TagLimit;
Neither of which seems to have any affect on the hashes at runtime.
Both of the above work properly, however, when I add them directly into
Tickets_Overly.pm
My question is if anyone knows of a way to update these hashes without
modifying Tickets_Overlay (keep the update in Tickets_Local). I would
guess this is a problem of scope, but I haven’t yet been able to find a
way around it (including completely commenting out the FIELDS and
dispatch declarations in Tickets_Overlay).
In your _Local file are you setting the package name?
Reproduced problem, this hashes are defined with ‘my’ scope so you
can’t redefine them from other file even if package is the same, but
you can redefine or tie hook on functions FIELDS, dispatch and
can_bundle.On 3/4/06, Michael Gilbert mdgilb@u.washington.edu wrote:
Yes, I am setting the package name in Tickets_Local. I should mention
that all previous changes have worked fine in Tickets_Local and all the
other _Locals, but all those changes were to existing or new
subroutines, not hash definitions.
For example, the &_TagLimit routine mentioned below is read without any
problems, and it only exists in the _Local, not the _Overlay. It’s only
the hash definitions that I can’t seem to add to.
Thanks,
Michael
Todd Chapman wrote:
On Fri, Mar 03, 2006 at 01:12:14PM -0800, Michael Gilbert wrote:
Hello,
I’m having what is likely a simple problem, but I haven’t been able to
come up with the answer on my own yet and was hoping for some advice.
What I’m trying to do is add keys to the %FIELDS and %dispatch hashes in
Tickets_Local in order to handle searches on a custom Tags table,
however the new keys are never properly added to the hashes. I’ve
attempted including them directly in the hash declarations:
%Fields =
…
Tag => [ ‘TAG’, ],
Tags => [ ‘TAG’, ],
%dispatch =
…
TAG => &_TagLimit,
As well as adding them in after the fact:
$FIELDS{‘Tag’} = [‘TAG’];
$FIELDS{‘Tags’} = [‘TAG’];
$dispatch{‘TAG’} = &_TagLimit;
Neither of which seems to have any affect on the hashes at runtime.
Both of the above work properly, however, when I add them directly into
Tickets_Overly.pm
My question is if anyone knows of a way to update these hashes without
modifying Tickets_Overlay (keep the update in Tickets_Local). I would
guess this is a problem of scope, but I haven’t yet been able to find a
way around it (including completely commenting out the FIELDS and
dispatch declarations in Tickets_Overlay).
In your _Local file are you setting the package name?
I still seem to be having some problems with this… How would I go
about redefining the FIELDS and dispatch subroutines with the extra
values, exactly? I still can’t seem to add the values to the hashes
without modifying Tickets_Overlay.
Thanks,
Michael
I keep running into problems in customizing Display.html, particularly
when doing redirects. Firstly, I want to add some calls like in
ModifyAll to things like ProcessCustomFields, then I want a conditional
redirect similar to the $m->redirect line that is already there.
However I keep getting stuck in loops where the page redirects to itself
until my browser starts sobbing.
I think the cause of the problem is probably the naming of
/Elements/ListActions, and it’s single parameter “actions”. I think
this parameter should have been called “results” (or maybe
"reactions"). It seems to me that someone got confused when writing the
code for Display.html, and muddled @Actions up with @results, but I
can’t quite figure out exactly where the problem lies.
Is there a mix up here, or am I the one mixed up? If there is a mix-up,
has anyone succeeded in untangling @Actions and @results so that the
code makes sense? Any help or thoughts apreciated.
As a resolution, I got the new hash values to be properly read by
deleting Tickets_Overlay_SQL from %INC before the module was loaded from
Tickets_Local. The module had previously not been loading with the new
hash values due to require’s insistence that modules not be previously
loaded.
So adding "delete $INC{‘RT/Tickets_Overlay_SQL.pm’};"
before "require RT::Tickets_Overlay_SQL;"
in Tickets_Local solved the problem. I wasn’t entirely clear on
Ruslan’s suggestion below, so thought I’d post this in case anyone else
runs into a similar problem.
Thanks,
Michael