[Openvas-devel] [RFC PATCH] Allowing filtering of issues during report export
openvas at markwallis.id.au
Tue Feb 24 14:05:52 CET 2009
On 23/02/2009, at 8:33 PM, Felix Wolfsteller wrote:
> I took a quick, second look at your patch.
> What is missing imho:
> * The filter does not effect nbe and pdf export if i am not
> mistaken. Quite
The filter as it stands does not affect NBE, XML or PDF. I agree that
I should get this working for PDF.
For NBE/XML though I feel these are a special case. The format types,
to me, can be broken into two groups.
HTML, Latex, Text, HTML_Graph and PDF all represents "reports" that
can you generate from the data.
NBE and XML though represent exports of the data itself into another
I'm thinking, perhaps we should be breaking these into two separate
menu items. A 'Report' feature and an 'Export' feature. I cannot see
the business case where filtering data out of an NBE/XML export would
Worst case, perhaps I should gray the new combo box out when NBE or
XML is selected as the format ?
> * A solution with bit sets instead of defines (SAVE_DETAIL_ALL,
> SAVE_DETAIL_HIGHMED) might make it easier to incorporate other
> levels at a
> later stage. This could be reflected in the GUI by checkboxes (so
> that you
> could en/disable every level for itself), but I find atm the
> combobox work
> equally fine. I was sure that the GLib brings a handy support for bit
> sets/masks, but I do not find it right now.
Good idea. I can rework things to use bitmasks behind the scene's. I
suggest though leaving the combo box as is rather than replacing it
with a list of check box's. At this stage, with only three levels of
detail, I think the dropdown box is usable enough without making the
page any more cluttered.
> But I also see that report generation needs a lot of care.
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 ?
mwallis at serialmonkey.com
More information about the Openvas-devel