Field Refactoring
This is a development scratch pad to outline a few of the requirements and ideas about how to better handle the ticket fields.
For now, this puts aside the generalization of such fields to other objects/resources than Tickets (see GenericTrac for that, 0.12 material).
Goals
Get an "adapted" rendering of standard and custom fields, in the following situations:
- Display of the field's value in the Ticket Box and other similar places (e.g. query and report results)
- Display of the field's value changes, in the Change History and other similar places (e.g. timeline, notification)
- Display of a field editor in the "Properties" fieldset and other similar places (e.g. bulk editor)
- Display of a field selector in the Query view
Some points to consider:
- the distinction between regular and custom types should become fairly transparent at the web UI level (leave the door open for unification later in GenericTrac) -- this is (was, even) already the case
- a rendering flexibility similar to the one of "Browser" properties should be reached (see source:trunk/trac/versioncontrol/web_ui/browser.py and source:trunk/trac/versioncontrol/web_ui/changeset.py)
- there should be some forward thinking for #2464. Possibly #3281 and the functionality of TH:SimpleTicketPlugin could be implemented.
- other simple additional features: field hints, wiki labels (#925), wiki fields (#1791)...
Proposal
A new API for dealing with fields according to the 4 points detailed above should be introduced. The old 0.9 - 0.11 API should be preserved, as there's a bunch of scripts all over the Trac world that probably depend on it, so ideally no existing method should be modified (I'm thinking in particular to TicketSystem.get_ticket_fields).
Instead, a new set of methods and objects should be introduced. In order to avoid any confusion between the old and new ways, I propose to use the term property instead of field. This matches the user-visible Properties label displayed in the ticket UI.
There will be a Property class and a set of basic subclasses that correspond to the main types of fields. A resource (tickets only for now) will define the set of properties that it provides (first in TicketSystem.get_ticket_properties(), but preferably later in TicketDescriptor.get_properties(), with TicketDescriptor a subclass of ResourceDescriptor, the generic handle for resources).
A Property subclass will have methods and attributes for answering the needs enumerated above.
- render(context, name, mode, value) - similar to the render_property of the trac.versioncontrol.browser.IPropertyRenderer (probably some kind of unification is in order)
- multiple other methods checking for the 'visibility' status of the field, 'row' display mode, etc. Each time with a given 'mode', which would be one of: 'ticket', 'ticket_preview', 'query'
- render_change(old_context, new_context, name, mode, old_value, new_value) - similar to the render_property_diff of the trac.versioncontrol.changeset.IPropertyDiffRenderer
- render_editor(context, name, mode, value). There could also be a validation method supporting validation requests that would be handled by a generic property module.
- render_selector(context, name, mode, values), for e.g. the query module.
Related Tickets
- #1449
- Trac does not check for conflicts with custom fields, Action box disappears
- #2464
- Conditional fields in tickets
- #2530
- Search doesn't work on custom fields
- #3281
- make Keywords field optional
- #3919
- Notifications use field name instead of label for custom fields
- #4061
- existing tickets should get the default value if value is not set in ticket
- #4374
- Custom Tickets Select Box Auto-generation
- #4549
- [PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...
- #5367
- New Priority Schema?
- #5526
- Support LIKE and wildcards in custom queries
- #5641
- Allow enums to be used in ticket custom value sets
