Hey all, I have a quick question for ya:
Do extension/plugin writers have a standard place to put settings or
configuration options? I’m building a small module and I’d like to
provide the ability to apply it only to certain queues. At present, I
have an array in RT_SiteConfig.pm for this configuration option, but
this is kind of a pain. I’d like to add a tab to the "Preferences"
section instead, but I’m not sure where to store the results.
Is there a standard way to do this (like creating a new table in the
DB, for example)?
Alternatively, is there any specific storage method to avoid?
Thanks!
Dan Thomson
Hey all, I have a quick question for ya:
Do extension/plugin writers have a standard place to put settings or
configuration options? I’m building a small module and I’d like to
provide the ability to apply it only to certain queues. At present, I
have an array in RT_SiteConfig.pm for this configuration option, but
this is kind of a pain. I’d like to add a tab to the “Preferences”
section instead, but I’m not sure where to store the results.
Is there a standard way to do this (like creating a new table in the
DB, for example)?
Alternatively, is there any specific storage method to avoid?
The two typical ways to do this are to use either RT::Attribute or
RT_SiteConfig.
What are you actually trying to build?
-j
Do extension/plugin writers have a standard place to put settings or
configuration options? I’m building a small module and I’d like to
provide the ability to apply it only to certain queues. At present, I
have an array in RT_SiteConfig.pm for this configuration option, but
this is kind of a pain. I’d like to add a tab to the “Preferences”
section instead, but I’m not sure where to store the results.
Is there a standard way to do this (like creating a new table in the
DB, for example)?
Alternatively, is there any specific storage method to avoid?
Extensions can also have their own configuration files in
plugins/RTx-Foo/etc/Foo_Config.pm
plugins/RTx-Foo/etc/Foo_SiteConfig.pm
They obviously get loaded later, which can be a benefit and a curse.
I do not recommend using RT config’s hash data type.
Setting variables of this type clobbers existing hashes, rather than
setting the specific keys in an existing hash (would make it more
useful for customization of defaults).
Cambridge Energy Alliance: Save money. Save the planet.
I was trying to implement a convenient configuration for my “subject
tagging” that I had mentioned earlier.
In the end, I took the advice from this list and used the
header-to-custom field scrip to import the necessary values from email
headers, then made my own scrip to apply certain custom fields to the
subject. It seems to work well, and each scrip/template can be created
per Queue which is all well and good, but I also wanted a convenient
way to disable this functionality with the click of a button instead
of by deleting a scrip. That’s why I wanted some kind of storage
method. I wanted to know which Queues had this functionality enabled
and disabled.
RT::Attribute seemed to do the trick.
I appreciate the help!2009/3/26 Jesse Vincent jesse@bestpractical.com:
On Thu 26.Mar’09 at 13:33:02 -0400, Dan Thomson wrote:
Hey all, I have a quick question for ya:
Do extension/plugin writers have a standard place to put settings or
configuration options? I’m building a small module and I’d like to
provide the ability to apply it only to certain queues. At present, I
have an array in RT_SiteConfig.pm for this configuration option, but
this is kind of a pain. I’d like to add a tab to the “Preferences”
section instead, but I’m not sure where to store the results.
Is there a standard way to do this (like creating a new table in the
DB, for example)?
Alternatively, is there any specific storage method to avoid?
The two typical ways to do this are to use either RT::Attribute or
RT_SiteConfig.
What are you actually trying to build?
-j
Thanks!
–
Dan Thomson
List info: The rt-devel Archives
Dan Thomson