id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,branch,changelog,apichanges,internalchanges 4549,"[PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...",trebor74hr@…,Jonas Borgström,"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",enhancement,new,normal,1.0,ticket system,0.10,normal,,workflow custom fields,ryano@…,,,,