|Version 4 (modified by 9 years ago) ( diff ),|
This is a development scratch pad to outline a few of the requirements and ideas about how to better handle the ticket fields.
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)…
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
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 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
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:
- 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:
render_change(old_context, new_context, name, mode, old_value, new_value)- similar to the
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.
- Bug dependencies/relations feature
- [PATCH] Allow wiki syntax in labels for custom fields
- Percentage complete
- Conditional fields in tickets
- Custom field sorts only as text
- Custom Tickets Select Box Auto-generation
- [PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...
- New Priority Schema?
- Support LIKE and wildcards in custom queries
- Allow enums to be used in ticket custom value sets
- restrict ticket properties to add/edit only/...
- Ticket should contain a field for the expected time to complete/fix it
- Optional validation for custom fields
- [PATCH] Support list of users as options list in ticket custom field
- Encourage users to select meaningful values for 'required' fields
- if SVN is used, milestone should manage/allowtoassign links for branch and tag
- Ticket should be divisible
- [PATCH] Improve ticket fields with tooltips
- Impossible to CC a username with spaces
- TicketQuery groups without translation
- Search through all text fields
- Batch Modification of Custom Text Area
- Add a custom field admin panel
- Add ICustomFieldTypeProvider interface