Ramon Ribó <ram...@...> writes:

> 
> > In the newest version, you can call the report by its name 
> 
> This is nice, but I was meaning that it was difficult for me to
> understand the help text. Maybe, it is difficult for someone else too.

OK, i've changed the default. I'm describing the title first. The number is
added as advanced feature.

> >>   1- ...
> >
> > This doesn't help, because after reconfiguring, the columns in the gui do
> > not match the report, though it has the correct name.
> >
> >>   2- ...
> >
> > You don't know the table structure and so you cannot give a correct aql
> > statement.
> >
> >>   3- ...
> >
> > This would work
> 
> Neither of the 3 solutions will work for ALL ticket configurations.
> However, I am sure that they will give meaningful results for 95% of
> the fossil repositories out there. And this is enough for a
> standardized GUI. If someone defines a ticket without "status" field
> or with strange fields, then he is not going to use the commodity
> mechanism offered by the GUI for dealing with the tickets. They will
> continue doing it by hand as they do it now.

I'll add a special report number 0, which lists all columns, defined in the
table. THis report can be used by a gui, the filter can be given as last
argument in the form "status<>'fixed' and ...".
What about the encoding of tickets. 

I don't want to hard code a special column(status) in the sources. Fossil is
fully configurable and this shouldn't be changed.

Quoting the output:
I don't think, it's neccessary to define a special row limiter. Each ticket
will be written on one line. I'll add an option to select between to encodings
of tickets:
1. the actually implemented version, which uses the same algorithm as the raw
   option on the show report page (usefull for a quick look by humans)
2. The fossil internal coding of special chars(space -> \s, tab -> \t,
   newline -> \n, cr -> \r, formfeed -> \f, vtab -> \v, nul -> \0, \ -> \\).
   This can easily be parsed with standard limiter tab(useful for linking guis).

The actual help text is listed below. If you have a proposal for a better,
feel free to send it to me.

E:\test 19:52:20,35 >fossil help ticket
Usage: fossil.exe ticket SUBCOMMAND ...

Run various subcommands to control tickets

    fossil.exe ticket show (REPORTTITLE|REPORTNR) ?TICKETFILTER? ?options?

        options can be:
          ?-l|--limit LIMITCHAR?
          ?-q|--quote?

        Run the the ticket report, identified by the report title
        used in the gui. The data is written as flat file on stdout,
        using "," as separator. The seperator "," can be changed using
        the -l or --limit option.
        If TICKETFILTER is given on the commandline, the query is
        limited with a new WHERE-condition.
          example:  Report lists a column # with the uuid
                    TICKETFILTER may be [#]='uuuuuuuuu'
        If the option -q|--quote is used, the tickets are encoded by
        quoting special chars(space -> \s, tab -> \t, newline -> \n,
        cr -> \r, formfeed -> \f, vtab -> \v, nul -> \0, \ -> \\).
        Otherwise, the simplified encoding as on the show report raw
        page in the gui is used.

        Instead of the report title its possible to use the report
        number. Using the special report number 0 list all columns,
        defined in the ticket table.

    fossil.exe ticket list

        list all columns, defined in the ticket table

    fossil.exe ticket set TICKETUUID FIELD VALUE ?FIELD VALUE ... ?

        change ticket identified by TICKETUUID and set the value of
        field FIELD to VALUE. Valid field descriptions are:
           status, type, severity, priority, resolution,
           foundin, private_contact, resolution, title or comment
        Field names given above are the ones, defined in a standard
        fossil environment. If you have added, deleted columns, you
        change the all your configured columns.
        You can use more than one field/value pair on the commandline.

    fossil.exe ticket add FIELD VALUE ?FIELD VALUE ... ?

        like set, but create a new ticket with the given values.

The values in set|add are not validated against the definitions
given in the "Ticket Common Script".


_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to