Version 8 (modified by 18 years ago) ( diff ) | ,
---|
Workflow Discussion
The original proposal is at NewWorkflow. The workflow sandbox is an attempt to implement an API for making the ticket system more generic.
Tasks
Add adisabled
attribute to fields so that workflow hooks can disable fields but still leave them visible.Add ahidden
attribute for the same reason. I've actually already done this, simply by renaming theskip
attribute tohidden
. Did this to be more consistent with HTML.Add a[2833]fullrow
attribute which signifies that the form element will span both columns of the ticket property fieldset. eg. summary, type, description and reporter would all befullrow=1
(done, but code in the templates is not implemented).Remove code specific to individual fields from ticket.cs/newticket.cs. The summary, type, description and reporter would be converted to use the the same generic code as the rest of the fields.[2833]Remove large[2833]if/elif
statement from ticket.cs/newticket.cs. Currently there is a large if/then/else style block which is used to display all fields other than the four described above. This could be removed and replaced with a call to form_control().In order to specify the order the generic field display code would use, the above changes would probably require the ticket.fields.* HDF branch to be changed to an array (currently it is a dict). This change would be in api.py (return fields in the correct display order) and the .cs files, possibly elsewhere.[2832].If possible I would also like to factor out the ticket field display/edit code from both ticket.cs and newticket.cs into ticket_fields.cs, as the template code is basically functionally identical.[2833]- Add a
.onchange
option for javascript field validation. - Add a
.title
option, or maybe.tooltip
, though I think for the sake of consisteny it should be.title
. - Add a
checkbox
field type. This would store the data in the field value ascheck1|check2|check4
. I'm not sure about this one, or how it would be presented in the query module, but I figured that people might find it useful. - Remove
ticket_custom_props()
macro? It does not appear to be referenced. Need a clean way to differentiate between fields that should not be displayed in the summary and those that should not be displayed at all. eg.[2837]summary
should be hidden in the ticket summary (as it is used for the title), and should only be editable by users withTICKET_ADMIN
privileges. Perhaps the logic should be that if a field ishidden
it is not displayed anywhere, unless it is alsoeditable
, in which case it is only displayed in the ticket properties.- There are a number of locations in the ticket code where permissions are hard coded. As an example, the
TICKET_CREATE
permission is required to create a new ticket. Should this be overridable byITicketWorkflow
implementors?
Attachments (3)
-
workflow-edit.png
(16.2 KB
) - added by 18 years ago.
Ticket editing flowchart
-
workflow-new.png
(17.1 KB
) - added by 18 years ago.
New ticket flowchart
-
workflow.png
(32.6 KB
) - added by 18 years ago.
Unified workflow flowchart
Download all attachments as: .zip
Note:
See TracWiki
for help on using the wiki.