Update report_vuln to support tracking origin#19817
Conversation
|
|
||
| if opts[:task] | ||
| Mdm::TaskService.create( | ||
| Mdm::TaskService.where( |
There was a problem hiding this comment.
Without this change, multiple entries were being created
| end | ||
|
|
||
| ret[:service] = service | ||
| service |
There was a problem hiding this comment.
A hash was never being returned from this method, the value assigned to the hash entry was being returned - i.e. the Mdm::Service
adfoster-r7
force-pushed
the
update-report-vuln-to-support-tracking-origin
branch
2 times, most recently
from
983fd26 to
d59c6f0
Compare
adfoster-r7
force-pushed
the
update-report-vuln-to-support-tracking-origin
branch
from
d59c6f0 to
c768ec8
Compare
| it { is_expected.to respond_to :services } | ||
| it { is_expected.to respond_to :report_service } | ||
|
|
||
| describe '#report_service', if: !ENV['REMOTE_DB'] do |
There was a problem hiding this comment.
Looks like the API for the remote db needs more work for existing functionality to be tested; but will mark this as skipped for now: #18439
|
Note: Looks like this might be a weird pattern, as if a module is rerun multiple times - it will try to upsert the vuln model - and replace existing 'origin' definitions. This means if the user wants to see where a vuln came from - it will be the last reported module run. This might be fine, but for the scenario of regenerating older reports - the link between the task run and the associated vuln may now no longer exist. This might be an existing problem with our data model though. |
|
Will close this off; I don't think a single |
2 participants
Update
report_vulnto support tracking originVerification