| | 1 | = Field Refactoring = |
| | 2 | |
| | 3 | This is a development scratch pad to outline a few of the requirements and ideas about how to better handle the ticket fields. |
| | 4 | |
| | 5 | For now, this puts aside the generalization of such fields to other objects/resources than Tickets (see GenericTrac for that, [milestone:0.12] material). |
| | 6 | |
| | 7 | == Goals == |
| | 8 | |
| | 9 | Get an "adapted" rendering of standard and custom fields, in the following situations: |
| | 10 | 1. Display of the field's value in the ''Ticket Box'' and other similar places (e.g. query results) |
| | 11 | 2. Display of the field's value changes, in the ''Change History'' and other similar places (e.g. timeline, notification) |
| | 12 | 3. Display of a field editor in the "Properties" fieldset and other similar places (e.g. bulk editor) |
| | 13 | 4. Display of a field selector in the Query view |
| | 14 | |
| | 15 | Some points to consider: |
| | 16 | - 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) |
| | 17 | - 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) |
| | 18 | |
| | 19 | |
| | 20 | ---- |
| | 21 | See: log:sandbox/field-refactoring-tmp |
