Ticket #4549 (new enhancement)
[PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...
| Reported by: | trebor74hr@… | Owned by: | jonas |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.0 |
| Component: | ticket system | Version: | 0.10 |
| Severity: | normal | Keywords: | workflow custom fields |
| Cc: |
Description
Hi,
First to say, I find Trac very useful and programmed nicely (appologies for my English).
Revision 5 is trac 0.10. Ticket fields std/custom improvements:
- field values (combo) filled with sql
- customized order of fields
- std fields - customized label/default values
- values - evaluation of variables
TRAC.INI with samples:
std fields default_* - default values order_* - order by (not applicable for some fields - e.g. ticket title) label_* - labels
custom fields req_who.options - sql filling the fields req_when.value = $(today) - variable evaluation *.order
I plan to implement following - but the question is when :(
- obligatory/optional/hidden field definition in ini
- init ticket callback - can change field definition (value, type, order ...)
- save ticket callback - can check/reject/change field values
- ticket initialization
- add to ticket/ticket_change "status by user" (like unread ticket, ticket, ...) can be used also as internal mail ... instead of sending the mail mark ticket/ticket_change to be read by some users
- customized home page for the user - will show number of unread tickets newly
- ticket "factory" for periodical tickets - e.g. one ticket generated for every month
It would be nice to have customized statuses, so in the future trac could be some kind of workflow system (add allowed state-transitions/persons). Each status could have extra fields, e.g. if status is "fixed" then field could be revision number.
Hope this will be useful.
Best regards from Croatia, Robert


