> 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.


>>   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.

RR


2010/10/5 Wolfgang <rat...@stumvolls.de>:
> Ramon Ribó <ram...@...> writes:
>
>>
>>   Hi,
>>
>>   It was not easy for me to discover that REPORTNR refers to one of
>> the "report formats" listed in the "Tickets main menu page". I would
>> explain it more detailed in the help, maybe using REPORT_FORMAT_NUMBER
>> instead of REPORTNR
>
> In the newest version, you can call the report by its name :-)
>
>>   At the same time, as the result of this command is a table, there
>> should be two delimiters instead of one. One for the rows and another
>> one for the columns. Also, what to do when the delimiter character is
>> contained in one of the fields? Maybe you should check the CSV format
>> for ideas.
>
> Currently i'm using a function, already defined in the report source. Newlines
> and spaces are compressed in this variant. Quoting of the separators(strings!)
> is not implemented yet.
>
> I can add a secong option for line separators. If this is used, i could
> activate the separator quoting.
>
>>   Another problem is that this solution is not adequate for an
>> automatic GUI that should be useful for any fossil database. The GUI
>> cannot create automatically a new report format without user
>> permission and new fossil databases only contain by default the report
>> "All Tickets".
>>
>>   I see three solutions here:
>>
>>   1- All new fossil databases contain, by default, a report with name
>> "All open tickets" (then, the new command should permit to select it
>> by name)
>
> This doesn't help, because after reconfiguring, the columns in the gui do
> not match the report, though it has the correct name.
>
>>   2- The SQL for the report is embedded in the fossil command
>
> You don't know the table structure and so you cannot give a correct aql
> statement.
>
>>   3- Add a special subcommand:
>>
>>      fossil.exe ticket list -status Open fieldList ?-l|--limit LIMITCHAR?
>
> This would work
>
>>      This command only works for tickets that have a "status" field.
>> If a tickets table does not have the "status" field, nothing is
>> returned.
>
> The mapping should be configured in the gui.
>
> I'll take a look, how to implement a fully quoting report output and i'll
> add the list columns command.
>
>
>
>
> _______________________________________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
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