Actions
Bug #5490
closed
Extra erroneous reporting with ncf methods
Status:
Rejected
Priority:
3
Assignee:
Category:
Web - Compliance & node report
Target version:
-
Pull Request:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:
Description
Hi,
When using ncf methods within "normal" techniques (not rudderified ncf techniques), extra buggy reports are generated, e.g.:
R: @@${report_data[1]}@@result_success@@${report_data[3]}@@${report_data[4]}@@${report_data[5]}@@2014-09-05 10:11:38+00:00##0072d014-acc2-47cc-8b12-4ce9aba1c773@#Set values dms_xorg_rotation.rotation into /etc/sysconfig/DMS/xorg/rotation
[...]
R: @@${report_data[1]}@@result_success@@${report_data[3]}@@${report_data[4]}@@${report_data[5]}@@2014-09-05 10:11:38+00:00##0072d014-acc2-47cc-8b12-4ce9aba1c773@#Copying /etc/lftp.conf from /var/cache/DMS-rudder//etc/lftp.conf
I remember talking with Jonathan about a csv file that was expected to be present, but is only present with rudderified-ncf techniques, not normal techniques, thus the undefined report_data array.
Moreover, if one rudderified ncf technique exist, all reports will go to this technique. If you create a ncf technique "foo", all these unrelated reports will go to "foo" (because of ${report_data1} = foo)
Thanks.
Updated by Matthieu CERDA about 10 years ago
- Category set to Web - Compliance & node report
- Status changed from New to 8
- Assignee set to Nicolas CHARLES
- Priority changed from N/A to 3
Hm, do you know why this might happen nico ? :/
Updated by Jonathan CLARKE about 10 years ago
It looks to me like this should be fixed by the change in #5663. Could someone confirm?
Updated by Jonathan CLARKE almost 10 years ago
- Status changed from 8 to Rejected
Actions