Brad Anderson wrote:
Alec Thomas wrote:
Hi,
I'd like to make some changes to the way ticket fields are handled by
Trac, but wanted to see what you guys think before committing any code.
The reason for these changes is so that the workflow API can add hooks
which can control and validate fields in a more flexible manner.
Changes are (from least to most intrusive):
- Add a "disabled" attribute
- Add a "hidden" attribute
- Add a "fullrow" attribute
- Add a "checkbox" field type.
Is a "multiple-select" field possible? I'm not sure if you need
another table to pull this off, but I know
As a side note, there are already a few tickets about multiselect fields
(for components: see #1730, for custom fields: see #918,
the latter from me with an implementation for 0.8).
Also, IIRC, there's a constraint on the custom_ticket table that prevents
multiple key-values pairs with the same key.
What I did to workaround this limitation was to pack the values in a 'list'
(much like what is done for the CC field). Not a good solution, so probably
another table would be needed...
that we would like to have a "Customer" field, and if a ticket applies
to one or more customers, they could be selected in the list box.
ticket_mult_selects
+--------+----------+----------------+
| ticket | field | value |
+--------+----------+----------------+
| 123 | customer | Sun |
| 123 | customer | HP |
+--------+----------+----------------+
and so on.
The above (or something similar at the data level) is fine as long as your
''customer'' is simply a label...
But one day you may want to have more information attached to a
customer, and this reminds me the situation we currently have for
components.
For components, there's already a placeholder for a ''description'' field...
and if we implement that, one can expect the same kind of feature requests
that we're seeing for Milestones.
A milestone is already some kind of Trac object, though quite limited:
there are lots of pending requests for adding "expected" Trac object
capabilities (e.g. history for the description, ability to see Milestone
edits
in the Timeline, etc.)
That's why I think that instead of putting the effort on the custom fields,
we should rather spend more effort on the Trac object model side,
and improve what we can do at that level.
In that perspective, a ticket object could be associated to multiple
customer objects.
One possible implementation would be to use the generalized relation table
(the xref table in the sandbox/trac-xref branch).
xref table:
+-------------+-----------+--------------+-------------+-------------+-----|
| source_type | source_id | relation | target_type | target_id | ... |
+-------------+-----------+--------------+-------------+-------------+-----|
| ticket | 123 | has-customer | wiki | CustomerSun | ... |
| ticket | 123 | has-customer | wiki | CustomerHp | ... |
+-------------+-----------+--------------+-------------+-------------+-----|
Alternatively, using an explicit ''customer'' type:
xref table:
+-------------+-----------+--------------+-------------+-------------+-----|
| source_type | source_id | relation | target_type | target_id | ... |
+-------------+-----------+--------------+-------------+-------------+-----|
| ticket | 123 | has-customer | customer | Sun | ... |
| ticket | 123 | has-customer | customer | HP | ... |
+-------------+-----------+--------------+-------------+-------------+-----|
The explicit type ''customer'' could either be a sub-type of Wiki page,
or even a new specialization of TracObject, with its own implementation.
One advantage of using a dedicated type for ''customer'' would be
the possibility to create TracLinks for such objects:
[customer:HP] => "HP" label, linked to the HP customer object
Even if there's no actual content associated to those customer objects,
the above implementation would make it possible to store many-to-many
relations between tickets and customers (even with different semantics,
e.g. by using multiple relations, like "reported-by" and "ordered-by").
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
