[Openvas-devel] [RFC PATCH] Allowing filtering of issues during report export

[Mark Wallis]

On 23/02/2009, at 8:33 PM, Felix Wolfsteller wrote:

> I took a quick, second look at your patch.

Thanks Felix.

> What is missing imho:
> * The filter does not effect nbe and pdf export if i am not  
> mistaken. Quite
> important.

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

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

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 ?

Regards,
Mark Wallis
mwallis at serialmonkey.com