Hey out there, I'm looking at using the FreeTextFields here, but these seem to only be available as associative hash arrays. While I find this useful, and like the combo box functionality, I'd still just like some extra "free text" fields associated with each ticket. Each of these will need to be new fields in the ticket table of course. I'll try and develop this so adding more fields is a matter of changing your for loop count. If anyone else is interested give a holler and I'll start throwing up some patch sets. -steve
Hi Steve, Steve Churchill wrote:
I'm looking at using the FreeTextFields here, but these seem to only be available as associative hash arrays. While I find this useful, and like the combo box functionality, I'd still just like some extra "free text" fields associated with each ticket. Each of these will need to be new fields in the ticket table of course. I'll try and develop this so adding more fields is a matter of changing your for loop count.
If anyone else is interested give a holler and I'll start throwing up some patch sets.
This means you are implementing a multi value free text field? If yes, just send a patch on the list. I'm very interested. :-)
-steve
Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
On Fri, 18 Mar 2005, Martin Edenhofer wrote:
Steve Churchill wrote:
I'm looking at using the FreeTextFields here, but these seem to only be available as associative hash arrays. While I find this useful, and like the combo box functionality, I'd still just like some extra "free text" fields associated with each ticket. Each of these will need to be new fields in the ticket table of course. I'll try and develop this so adding more fields is a matter of changing your for loop count.
If I can interject, changing the free-text field count is entirely the wrong way of handling this. It results in the same problem as hard-coded attachment counts, etc. There should really be a new table for "free_text_types" that allow admins/agents to create new field definitions. Each row in the table would define a type that would be referenced in another table, "free_text(s)". Each row in this table would be a unique free_text that would refer back to the ticket_id for the ticket it's associated with, and have a foreign key back to the free_text_types table. Not only does this scale by just looping through the array of $sth->fetchrow_hashref(s), but new free_text entries can based on existing "types" by referencing back to the free_text_types table and forming the basis for a drop-down. Does my rambling make any sense? :) -- Jason Dixon 301.286.8635 voice NASA / Goddard Space Flight Center jason@nccs.nasa.gov AMTI, Inc. Building 28, Room S212 Code 931
Hi Jason, Jason Dixon wrote:
I'm looking at using the FreeTextFields here, but these seem to only be available as associative hash arrays. While I find this useful, and like the combo box functionality, I'd still just like some extra "free text" fields associated with each ticket. Each of these will need to be new fields in the ticket table of course. I'll try and develop this so adding more fields is a matter of changing your for loop count.
If I can interject, changing the free-text field count is entirely the wrong way of handling this. It results in the same problem as hard-coded attachment counts, etc. There should really be a new table for "free_text_types" that allow admins/agents to create new field definitions. Each row in the table would define a type that would be referenced in another table, "free_text(s)". Each row in this table would be a unique free_text that would refer back to the ticket_id for the ticket it's associated with, and have a foreign key back to the free_text_types table. Not only does this scale by just looping through the array of $sth->fetchrow_hashref(s), but new free_text entries can based on existing "types" by referencing back to the free_text_types table and forming the basis for a drop-down.
Does my rambling make any sense? :)
IMO it make sense! .-) We also was thing about a reference table for ticket free text attributes. The only reason because we implemented ticket free text attributes this way is because of the performance of complex searches and a lot of ticket (> 1.000.000). We tried different ways and the current one was the way with the best performance (of course a reference table whould be elegant way). Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
On Tue, 22 Mar 2005, Martin Edenhofer wrote:
We also was thing about a reference table for ticket free text attributes. The only reason because we implemented ticket free text attributes this way is because of the performance of complex searches and a lot of ticket (> 1.000.000).
We tried different ways and the current one was the way with the best performance (of course a reference table whould be elegant way).
Which brings up the problem with a lack of foreign key support in MySQL's MyISAM tables. I'm not sure if this is in the works for MySQL 5.0, but it's available in the InnoDB table format as well as PostgreSQL (and just about any other "real" RDBMS). These really need to be utilized in OTRS 2.x. I don't see why existing tables can't be migrated over to InnoDB easily. This would allow us to move all these hardcoded data types (attachments, freetext, etc) to "reference tables". -- Jason Dixon 301.286.8635 voice NASA / Goddard Space Flight Center jason@nccs.nasa.gov AMTI, Inc. Building 28, Room S212 Code 931
Hi Jason, Jason Dixon wrote:
We also was thing about a reference table for ticket free text attributes. The only reason because we implemented ticket free text attributes this way is because of the performance of complex searches and a lot of ticket (> 1.000.000).
We tried different ways and the current one was the way with the best performance (of course a reference table whould be elegant way).
Which brings up the problem with a lack of foreign key support in MySQL's MyISAM tables. I'm not sure if this is in the works for MySQL 5.0, but it's available in the InnoDB table format as well as PostgreSQL (and just about any other "real" RDBMS). These really need to be utilized in OTRS 2.x. I don't see why existing tables can't be migrated over to InnoDB easily. This would allow us to move all these hardcoded data types (attachments, freetext, etc) to "reference tables".
Attachments are not hardcoded with counter. It's only article and ticket free text fields. -=> I put it on the todo list to do new tests (incl. InnoDB) and in case to move it to "reference tables". Anyway, thanks for your help! :) Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
On Tue, 22 Mar 2005, Martin Edenhofer wrote:
Attachments are not hardcoded with counter. It's only article and ticket free text fields.
Since when, 2.x? I recall attachments being hardcoded in 1.3. Thanks, -- Jason Dixon 301.286.8635 voice NASA / Goddard Space Flight Center jason@nccs.nasa.gov AMTI, Inc. Building 28, Room S212 Code 931
Jason Dixon wrote:
Attachments are not hardcoded with counter. It's only article and ticket free text fields.
Since when, 2.x? I recall attachments being hardcoded in 1.3.
Maybe I unserstand something wrong? But there is a extra attachments table which referes to the article table. me@kors:~/src/otrs-1.3> grep -r article_attachment scripts/database/ | grep CREATE scripts/database/otrs-schema.mysql.sql:CREATE TABLE article_attachment scripts/database/otrs-schema.postgresql.sql:CREATE TABLE article_attachment [...] -=> ftp://ftp.otrs.org/pub/otrs/misc/otrs-1.3-database.png What do you mean with "attachments being hardcoded in 1.3"? Thanks! Martin -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
On Tue, 22 Mar 2005, Martin Edenhofer wrote:
Maybe I unserstand something wrong? But there is a extra attachments table which referes to the article table.
me@kors:~/src/otrs-1.3> grep -r article_attachment scripts/database/ | grep CREATE scripts/database/otrs-schema.mysql.sql:CREATE TABLE article_attachment scripts/database/otrs-schema.postgresql.sql:CREATE TABLE article_attachment [...]
-=> ftp://ftp.otrs.org/pub/otrs/misc/otrs-1.3-database.png
What do you mean with "attachments being hardcoded in 1.3"?
Must be my mistake, perhaps I'm confusing them with freetext. Thanks for clarifying that. -- Jason Dixon 301.286.8635 voice NASA / Goddard Space Flight Center jason@nccs.nasa.gov AMTI, Inc. Building 28, Room S212 Code 931
Hi Jason, Jason Dixon wrote:
Maybe I unserstand something wrong? But there is a extra attachments table which referes to the article table.
me@kors:~/src/otrs-1.3> grep -r article_attachment scripts/database/ | grep CREATE scripts/database/otrs-schema.mysql.sql:CREATE TABLE article_attachment scripts/database/otrs-schema.postgresql.sql:CREATE TABLE article_attachment [...]
-=> ftp://ftp.otrs.org/pub/otrs/misc/otrs-1.3-database.png
What do you mean with "attachments being hardcoded in 1.3"?
Must be my mistake, perhaps I'm confusing them with freetext. Thanks for clarifying that.
No problem. I like your helpful suggestions! ;) Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
participants (3)
-
Jason Dixon -
Martin Edenhofer -
Steve Churchill