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:

1. Display of the field's value in the Ticket Box and other similar places (e.g. query results)
2. Display of the field's value changes, in the Change History and other similar places (e.g. timeline, notification)
3. Display of a field editor in the "Properties" fieldset and other similar places (e.g. bulk editor)
4. 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)
• 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​)

---

See: log:sandbox/field-refactoring-tmp