Edgewall Software

Changes between Version 38 and Version 39 of WorkFlow


Ignore:
Timestamp:
Apr 12, 2006, 12:36:32 PM (18 years ago)
Author:
Alec Thomas
Comment:

Some updates on what has changed recently

Legend:

Unmodified
Added
Removed
Modified

  • WorkFlow

    v38 v39  
    4747(most?) aspects.
    4848
    49 {{{
    50 #!python
    51 class ITicketFieldProvider(Interface):
    52     """ Provide custom ticket fields programmatically. Allows plugins to supply
    53         fields without manipulation of the [ticket-custom] section of the
    54         trac.ini file. """
    55 
    56     def get_ticket_fields():
    57         """ Return an iterable of custom trac.ticket.field.Field objects. """
    58 
    59     def validate_ticket_field(field, value):
    60         """ Validate custom ticket field value after user submission. """
    61 
    62 class ITicketFieldTypeProvider(Interface):
    63     """ Provide custom ticket field types (subclasses of
    64         trac.ticket.field.Field). """
    65 
    66     def get_ticket_field_types():
    67         """ Return list of (name, type) tuples, where type is a
    68             subclass of trac.ticket.field.Field. """
    69 
    70     def validate_ticket_field_type(field, value):
    71         """ Validate a field of type provided by this extension. """
    72 
    73 class ITicketManipulator(Interface):
    74     """ Miscellaneous manipulation of ticket workflow features. """
    75     def prepare_ticket_for_render(self, req, ticket, fields, actions):
    76         """ Prepare the ticket fields and actions for rendering. Fields and
    77             actions can both be modified. """
    78 
    79     def validate_ticket(self, req, ticket):
    80         """ Validate ticket state after population from user provided values. """
    81 
    82 class ITicketActionController(Interface):
    83     """ Allows plugins to add and control ticket actions. """
    84 
    85     def get_ticket_actions(req, ticket):
    86         """ Return an iterable of actions that are available given the current
    87             state of ticket and the request object provided. """
    88 
    89     def get_ticket_action_controls(req, ticket, action):
    90         """ Return an iterable of tuples in the form (label, (control, ...)).
    91             Where control is an trac.ticket.field.Field object. """
    92 
    93     def apply_ticket_action(req, ticket, action):
    94         """ Perform action on ticket. """
    95 }}}
    96 
    97 
    9849== Tasks ==
    9950=== Done ===
    … …  
    10859 * Add a `.plaintext` option which negates the default behaviour of WikiFormatting field labels and values (see #925, #1395 and #1791 for related information). [2849]
    10960 * Add a `.title` option, or maybe `.tooltip`, though I think for the sake of consisteny it should be `.title`. [2851]
     61 * 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 by `ITicketWorkflow` implementors?
     62 * It might be an idea to simply have a `apply_ticket_changes()` method instead of having `apply_ticket_action()` and `update_ticket_fields()`.
    11063
    11164=== TODO ===
    112  * Add an `.onchange` option for javascript field validation.
    113  * Add a `checkboxes` field type. This differs from the `checkbox` type in that it is a set of related checkboxes. It would store the data in the field value as `check1|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. Similarly, a `multi_select` type could be useful.
    11465 * Remove `ticket_custom_props()` macro? It does not appear to be referenced.
    115  * 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 by `ITicketWorkflow` implementors?
    116  * It might be an idea to simply have a `apply_ticket_changes()` method instead of having `apply_ticket_action()` and `update_ticket_fields()`.
    117  * Add a `percentage` field type? Represented as a bar like in the milestone:0.10 view, except if you click on a position in the bar it sets the field value. This could probably just be done by setting `html_value` appropriately.
    11866
    11967== Basic Configurable Workflow ==
    … …  
    160108== Available Field Types and Options ==
    161109Common options:
     110 * '''name''': Field name.
    162111 * '''label''': Descriptive label.
    163112 * '''value''': Default value.
    164  * '''html_value''': This option is most useful to plugins. If it exists it is the content displayed instead of the normal '''value'''. This can be useful for fields with ticket ID's, to display the correct TracLinks for the tickets.
    165113 * '''order''': Sort order placement. (Determines relative placement in forms.)
    166  * '''hidden''': Field is not displayed. Useful for storing extra ticket attributes programmatically (false by default).
     114 * '''visible''': Whether field is visible. Useful for storing extra ticket attributes programmatically (false by default).
     115 * '''editable''': Field is editable (true by default if field is '''visible'''). If a field is hidden but editable, it will not display in the ticket summary but will be displayed and editable in the ticket properties.
    167116 * '''fullrow''': Field spans a full row when displayed in the ticket properties.
    168  * '''editable''': Field is editable (true by default if field is not hidden). If a field is hidden but editable, it will not display in the ticket summary but will be displayed and editable in the ticket properties.
    169117 * '''plaintext''': Field labels and values use WikiFormatting by default. To display plain text set this option to true.
    170118 * '''title''': HTML title (tooltip) for this field.