[Openvas-devel] [RFC PATCH] Allowing filtering of issues during report export
felix.wolfsteller at intevation.de
Wed Feb 25 09:57:02 CET 2009
> On Dienstag, 24. Februar 2009, Mark Wallis wrote:
> > The switch() in report-save.c:file_save_ok_callback does seem a little
> > confusing to me in the way that each report type is generated slightly
> > differently. For example, the HTML and latex types both use the
> > backend_convert function and then pass the returned arglist through
> > another function which does the formatting. The XML_NG clause though
> > uses a specialised backend_to_xml_ng function, and the PDF clause uses
> > a completely different method all together.
> > Perhaps there is a way that we can clean this area of code up to allow
> > us to easily add new report types down the track ?
A couple of unordered words from my side:
Besides code and report consistency issues I also find the current export-
dialog quite unhandy, as it does not memorize the type selection or location
and will e.g. create "report.pdf.nbe" if you forgot to select pdf as type.
Imho the direction to go is to generate all reports from one 'base' format but
using syntactical rules only. The wording should be kept exchangable (look
e.g. at the latex_output's introductions, I see no reason for that being
hard-wired in the latex_output module).
Apparently quite some users rely on the nbe format so that we cannot drop
support for it. Otherwise I would go for using xml as standard format.
Your point about 'data' and 'report' is correct, although I think we could
easily generate fancy reports from xml using xslt (and afaict filter them as
Maybe an extended menu (but keeping the old item items) would make sense, too:
* export as
* export -> pdf- report
Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
More information about the Openvas-devel