Hi,
I'd like to make some changes to the way ticket fields are handled by
Trac, but wanted to see what you guys think before committing any code.
The reason for these changes is so that the workflow API can add hooks
which can control and validate fields in a more flexible manner.
Changes are (from least to most intrusive):
- Add a "disabled" attribute to fields so that workflow hooks can
disable fields but still leave them visible (done).
- Add a "hidden" attribute for the same reason. I've actually already
done this, simply by renaming the "skip" attribute to "hidden". I
did this to be more consistent with HTML (done).
- Add a "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 be "fullrow=1" (done, but
code in the templates is not implemented).
- Add a "checkbox" field type. This 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.
- 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.
- Remove large "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.
- 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.
So, please let me know what you think of these changes.
Alec
On Tue, Jan 17, 2006 at 05:12:56PM +1100, Alec Thomas wrote:
> Hi again,
>
> I've committed a version into the sandbox, based on the original patch
> from TracHacks.
>
> I've also just implemented configuration options for defining ticket
> status transitions. The format is described here [1].
>
> Alec
>
> [1] http://trac-hacks.org/ticket/128
>
> On Fri, Jan 13, 2006 at 11:29:19PM +1100, Alec Thomas wrote:
> > Hi,
> >
> > The patch and plugin are in a relative "stable" state and the
> > transitions seem to work as described on the new work flow page.
> >
> > I'd like to make the transitions configurable, and have created a ticket
> > to discuss it here [1].
> >
> > Alec
> >
> > [1] http://trac-hacks.swapoff.org/ticket/128
> >
> > On Fri, Jan 13, 2006 at 03:45:30PM +1100, Alec Thomas wrote:
> > > I've put the patch, and the beginnings of a plugin that implements the
> > > NewWorkflow ideas, up on TracHacks [1].
> > >
> > > I've fixed the JavaScript so it now disables the form elements.
> > >
> > > It's made the ticket action clearsilver code a lot more generic too,
> > > removing the big "if/else" block.
> > >
> > > [1] http://trac-hacks.swapoff.org/wiki/WorkFlowPatch
> >
> > --
> > Evolution: Taking care of those too stupid to take care of themselves.
> > _______________________________________________
> > Trac-dev mailing list
> > [email protected]
> > http://lists.edgewall.com/mailman/listinfo/trac-dev
> >
>
> --
> Evolution: Taking care of those too stupid to take care of themselves.
> _______________________________________________
> Trac-dev mailing list
> [email protected]
> http://lists.edgewall.com/mailman/listinfo/trac-dev
>
--
Evolution: Taking care of those too stupid to take care of themselves.
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
