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!