I am thinking that composite custom fields would be useful.
A composite CF is a CF composed of other CFs, so you could
group related information together. Or, you might want to
have a description with an image, or a status with a file
upload document.
Worthwhile?
-Todd
I am thinking that composite custom fields would be useful.
A composite CF is a CF composed of other CFs, so you could
group related information together. Or, you might want to
have a description with an image, or a status with a file
upload document.
Autrijus Tang prototyped this in his branch of RT 3.{0,2}. I think all
that’s missing to do it in 3.3 is UI.
Would there be any value in a ‘Date’ custom field? Would it
make querying easier for Date related CFs? We could at least
check for valid dates…
-ToddOn Fri, Nov 19, 2004 at 01:43:22PM -0500, Jesse Vincent wrote:
On Fri, Nov 19, 2004 at 12:49:14PM -0500, Todd Chapman wrote:
I am thinking that composite custom fields would be useful.
A composite CF is a CF composed of other CFs, so you could
group related information together. Or, you might want to
have a description with an image, or a status with a file
upload document.Autrijus Tang prototyped this in his branch of RT 3.{0,2}. I think all
that’s missing to do it in 3.3 is UI.Worthwhile?
-Todd
Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives–
Would there be any value in a ‘Date’ custom field? Would it
make querying easier for Date related CFs? We could at least
check for valid dates…
RT 3.3’s custom fields system supports regex validation and other
arbitrary type information behind the scenes. We had to draw a line in
terms of what we could actually ship in finite time as RT 3.4, but many
more custom field types and more exposed options are going to happen in
the future.
Jesse
Jesse,
I see that. Date CFs seems like they will be extra hard because
of not getting the features of a DB datetime field. Unless
date CFs maybe end up getting stored in their own table.
All this CF fancyness bring up another thought. With the
validation and, more importantly, the access controls on
CFs, they start to look a lot more attractive than, say,
some of the fields in the Ticket table. For example,
controlling who can change the ‘Due’ date.
It seems like in the future it would be attractive to have all
but a few fundamental fields be CFs. The transition could be made a lot
cleaner if the was some overloading so that if a Ticket field is
set but that field doesn’t exist then an existing CF of the same
name would be set. What thoughts have you?
-ToddOn Fri, Nov 19, 2004 at 06:13:31PM -0500, Jesse Vincent wrote:
On Fri, Nov 19, 2004 at 05:29:43PM -0500, Todd Chapman wrote:
Would there be any value in a ‘Date’ custom field? Would it
make querying easier for Date related CFs? We could at least
check for valid dates…RT 3.3’s custom fields system supports regex validation and other
arbitrary type information behind the scenes. We had to draw a line in
terms of what we could actually ship in finite time as RT 3.4, but many
more custom field types and more exposed options are going to happen in
the future.Jesse
It seems like in the future it would be attractive to have all
but a few fundamental fields be CFs. The transition could be made a lot
cleaner if the was some overloading so that if a Ticket field is
set but that field doesn’t exist then an existing CF of the same
name would be set. What thoughts have you?
That has terrifying performance implications. The custom fields are
much heavier than core fields. Particualrly for searching. There’s a
project we have in the lab that may make this a non-issue. But you’re
not likely to see anything on that front for quite a while.
-j