[PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...

[trebor74hr@…]

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

[trebor74hr@…]

trac/ticket/web_ui.py, api.py, trac/web/auth.py

[trebor74hr@…]

sample part of ini file

[Christian Boos]

Several interesting ideas… worth to be looked at.

#4374 already requested the ability to generate options from SQL queries.

Also, note that several of your "future" ideas are being worked on in the source:sandbox/pycon/workflow branch. You may want to comment on the WorkFlow page or join the discussions on the trac-dev MailingList.

[Christian Boos]

See also #2464.