[PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ... — at Version 4
|Reported by:||Owned by:||Jonas Borgström|
|Severity:||normal||Keywords:||patch workflow custom fields|
|Cc:||Ryan J Ollos||Branch:|
Description (last modified by )
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