Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Importer to work with new Finding Template API #4

Closed
richardschwabe opened this issue Jul 15, 2023 · 3 comments · Fixed by #46
Closed

Update Importer to work with new Finding Template API #4

richardschwabe opened this issue Jul 15, 2023 · 3 comments · Fixed by #46
Assignees

Comments

@richardschwabe
Copy link
Contributor

Respect new structure

This was referenced Jul 19, 2023
@richardschwabe richardschwabe self-assigned this Aug 4, 2023
richardschwabe pushed a commit that referenced this issue Aug 4, 2023
@richardschwabe richardschwabe linked a pull request Aug 4, 2023 that will close this issue
@richardschwabe
Copy link
Contributor Author

If we wanted to import a finding in multiple languages we are running into the issue, that we cannot reference the id of a finding.
i.e Scenario:
Get finding from X, upload to Sysreptor, set language to en-US, and set "is main" language.
Then get finding X but the translation is in German.
By this time, we might not have access to the correlating template ID from sysreptor of the finding. This means we cannot add the German translation to an existing sysreptor finding.

My suggestion is to have something like an "external_reference_id" or similar. This way we can store the original ID from the app X we are importing from.

This would also help to have a check, if a template has already been imported or not. Furthermore, we could ask the user to overwrite it or not.

@aronmolnar
Copy link
Contributor

I see the problem.

I suspect that this would be two executions of reptor:

  1. Get finding from X, upload to Sysreptor, set language to en-US, and set "is main" language.
  2. Then get finding X but the translation is in German. (and upload it)

Maybe for the sake of simplicity, we import finding templates as they were in the previous application.

If Defect Dojo does not support multilanguage finding templates, each finding is imported as a new finding template to SysReptor. This would mean, translations would not be aggregated.

If pwndoc-ng supports multilanguage finding templates, we can easily import those findings in one step.

What do you think?

@richardschwabe
Copy link
Contributor Author

Well, I guess everything comes down to the individual importer.

Some applications do not offer multi language. We don't need to worry about them.
They can be used as it is right now in the PR. --language en-US --main will set them up correctly.

For the multi language apps, it also comes down to the way they save their multi language findings.
I think, to solve the problem in the short term, we must enforce, that a finding template is uploaded with all language translations at the same time.

However, I think that the finding templates page needs to be reworked a little. For instance, it should be possible to select multiple findings at the same time and delete all selected items.
Most likely it should also be possible to filter by tag. That way we could tag each imported finding. Because at the moment they are completely stand-alone. It is not uncommon to have hundreds of findings over time, so going over each one by one is a bit overwhelming.
I think even an implementation similar to Wordpress's "quick edit" for multiple selected items would be great. Were it is possible to set the status of all items at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants