wolfgang <rat...@...> writes:
>
> Ramon Ribó <ram...@...> writes:
> :
> > So, It would be enough for this application to have the possibility of
> changing the status of the ticket.
> >
> > It would be also nice to have a more ordered list of tickets with its id,
> comment and status so as to avoid parsing "fossil timeline -t t"
> > RR2010/10/4 Richard Hipp <drh <at> sqlite.org>
> > On Mon, Oct 4, 2010 at 4:25 AM, Christian Busch
> <busch.christian <at> gmx.de> wrote:
> >
> :
> Hello
>
> I understand your requirements as follows:
>
> 1. fossil ticket set (status|type|severity|priority|resolution) value
> the problem is, that the allowed values are defined using th-script.
> 2. fossil ticket list <report-number>
> export the data, shown on the corresponding gui ticket report page, as
> simple text export(csv). By using the report definition mechanismen, we
> have full flexibility for reports and consistency with the gui.
> This shouldn't be a problem.
>
> I would implement it, if we can get a common sense about the things to do.
>
what about:
dmc>fossil help ticket
Usage: fossil.exe ticket SUBCOMMAND ...
Run various subcommands to control tickets
fossil.exe ticket list REPORTNR ?TICKETUUID?
Run the the ticket report, identified by the report number
used in the gui. The data is written as flat file on stdout,
using "," as separator.
If TICKETUUID is given on the commandline, only this ticket
is listed, if the report delivers the uuid, otherwise the
argument is ignored.
fossil.exe ticket set FIELD VALUE TICKETUUID
change ticket identified by TICKETUUID and set the value of
field FIELD to VALUE. Valid field descriptions are:
status, type, severity, priority or resolution
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
