Add rendersections plugin

[Neverbolt]

We recently had the need to be able to choose arbitrary sections of the report to be rendered or not, which was not possible with the existing renderfindings plugin. Therefore we developed the rendersections plugin, that gives the power of making sections selectable to the design author.

For more information about how the plugin works please see the README.md of the plugin.

As we are very happy with Sysreptor and a large portion of the code is based on the renderfindings plugin, we want to give back and contribute the rendersections plugin upstream.

[MWedl]

Hi, the plugin code looks good. However, I have got a remark about the functionality.

When first using the plugin, I was a bit confused that sections without an data-sysreptor-rendersections attribute are included in the PDF. I would have expected that only the chosen sections are included in the PDF and all other sections without an attribute are excluded. This plugin currently lets you choose which sections to exclude instead of which sections to include.

In comparison, the renderfindings plugin excludes all findings and sections by default and only includes chosen findings and explicitly included sections. For me this is the more intuitive approach, because in the design's HTML you have to mark the sections that you want to include in the PDF (e.g. via data-sysreptor-rendersections="include|choosable") instead of marking sections that you want to exclude (e.g. via v-if="!data.isPluginRenderFindings"`).

What do you think about the exclude vs. include approach? What is the reason why you implemented it that way, that I am missing?

[Neverbolt]

Hi,

I should have given a bit more justification for this to make it understandable why we needed it, you're right.

For us the issue was, that we needed different parts of the report for different stakeholders.
So for example just the management summary for sales colleagues so they know approximately about the results without getting too sensitive information.
Or a single issue rendered out so that it can be passed on to a system integrator / external IT company. (prime usecase for the existing renderfindings)
Or the ability to exclude the technical sections of each finding for non-technical managers.

This is why we wanted to make certain sections choosable. Everything that is not marked as choosable or related to a choosable section (eg we don't need a section explaining CVSS if there is no finding included that shows a CVSS score/string) is part of the outlining report structure and is always present.

This is also, why the binary v-if="!data.isPluginRenderFindings" was not sufficient for us, as we want to control sections that are not findings, and we want to control them individually.
Another usecase for this is eg including certain parts of the appendix depending on the findings that are included. We could even do that using the related attribute, but it's simpler to just have them choosable sections and manually enable them if needed.

So I agree, that the functionality can be seen both as including and excluding sections. The presentation is probably up to preference, but if you think this plugin can be useful for a broader audience and have an opinion on which of the two should be used I am very open for it.

Does this explain the open questions you had?

[MWedl]

Thanks for the detailed explanation. Yes, I think this plugin can be useful for many users and we are willing to provide and maintain it as an official plugin.

However, we would prefer an exclude default strategy similar to the renderfindings plugin. In my opinion a design author should only have to mark sections that should be included/choosable in the PDF (and exclude everything else) instead of marking sections that should be excluded/choosable (and include everything else). This way feels more intuitive - at least for me. The choosable and related features are great.

[Neverbolt]

I'm very glad to hear that!

We evaluated the "default include" vs "default exclude" decision at the beginning of development, and the reason why we went with the "default include" strategy is, because usually there are fewer sections where you want to make that choice than there are other high-/top-level HTML elements.
With a "default exclude" strategy, one needs to specifically mark things like the front page, headers/footers, etc as included, which was a bigger change to the design than necessary for "default include".

But if that's your preferred strategy give me a quick confirmation and I can make the necessary changes. I assume a data-sysreptor-rendersections="always" is going to be necessary, so that one can mark the common sections with it.

[MWedl]

It probably depends on the use case and what parts of the report should be present in the partial PDF.

Yes, exclude by default is our preferred strategy. It would be great if you could implement it. Thank you.