Mappings manager/migrate templates to db #1248
Conversation
…is/dradis-ce into mappings-manager/migrate-templates-to-db
| ) | ||
| end | ||
|
|
||
| def create_mapping_fields(mapping, template_file) |
There was a problem hiding this comment.
A lot of this, including regexp parsing and #update_syntax method seem to be separate concerns that should be encapsulated elsewhere?
The logic seems to replicate what we already have in
https://github.com/dradis/dradis-ce/blob/develop/app/models/field_parser.rb
and
https://github.com/dradis/dradis-plugins/blob/main/lib/dradis/plugins/templates.rb
If this class's responsibility is to turn .template fields into DB records, it seems that some other class/module/concern's should be understanding the actual content. Manipulating text seems a bit out of scope? Perhaps not it's just clarity and naming conventions.
| @integration_name = integration.plugin_name.to_s | ||
| set_integration_template_dirs | ||
|
|
||
| if integration.uploaders.count > 1 |
There was a problem hiding this comment.
We do we need to keep two separate code paths?
Isn't a single-uploader integration a particular case of a multiple-uploader integration, where the count is 1 (or collection has a single element)? That was the spirit of the architecture between multiple uploaders.
There was a problem hiding this comment.
The only reason for this check here is that for our integrations with multiple uploaders we renamed their templates since they were not following a convention. Since we renamed them, the Mapping source isn't going to match the name of the .template file so we had to handle these cases differently
Summary
This is a restore of the now closed #1232