You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported by Voices for Children Montgomery in the 2026-08-07 stakeholder sync. Distinct from #7093 — see "Not the same bug as #7093" below.
Impacted User Types
volunteers, case supervisors, and org staff at the reporting org — multiple people, not one machine
Environment
prod. Microsoft Edge on Windows. Downloading a generated court report .docx.
Current Behavior
Generating a court report succeeds, but the browser download is blocked with a "virus detected" warning. The user has to go into their antivirus software and tell it to ignore the detection to download anyway.
Stakeholder's words, from the sync:
Every time I download a report and other people download a report, it says viruses are detected. And then I have to go into like the virus detection software to say to ignore the virus and download anyway … which is kind of obnoxious and that's been happening for a while [approximately six months].
Note
Screenshot pending. A redacted screenshot of the Edge warning was captured during the sync and will be attached to this issue.
Expected Behavior
The generated .docx downloads without any antivirus or SmartScreen warning.
#7093 was "the file isn't in the correct format" when opening the report in Word, root-caused to zip64 (#7098, shipped 2026-08-06). This one fires earlier — at download time, in the browser, before Word is involved — and the stakeholder dates it to roughly six months, whereas the zip64 regression only started when the caxlsx bump floated us to rubyzip 3.x in April 2026.
That said, #7098 shipped the day before this was reported, so step one is re-testing: a structurally odd zip (version-needed 45, 0xFFFFFFFF size placeholders) is exactly the sort of thing antivirus heuristics dislike, so the fix may have taken this with it.
Leads, cheapest first
1. The download has no explicit filename — see #7099.CaseCourtReportsController#show (app/controllers/case_court_reports_controller.rb:22):
@casa_case.latest_court_report.opendo |file|
# TODO test this .read being present, we've broken it twice nowsend_dataFile.read(file.path),type: :docx,disposition: "attachment",status: :okend
There is no filename:, so the browser derives the download name from the URL path. #7093 produced a file named _C-15-JV-24-191.docx — leading underscore, not in the case number. A binary attachment with a browser-derived name, served from a Heroku app domain with no SmartScreen reputation, is a good match for the heuristic profile. Fixing #7099 (File.binread + explicit filename:) is the cheapest thing to try and is worth doing regardless.
2. Field codes left in the generated document. The org templates are full of Word MERGEFIELD … \* MERGEFORMAT field instructions — visible in the raw XML of default_report_template.docx, and heavily throughout montgomery_report_template.docx (the reporting org's own template). Sablon substitutes the «…» text but the surrounding field-code machinery stays in the package. A .docx carrying field codes is a classic malware-delivery shape (DDEAUTO / INCLUDEPICTURE), and Defender is aggressive about it. Hypothesis, not verified — worth checking whether the generated output retains field-code remnants, and whether a template stripped of MERGEFIELD instructions downloads cleanly.
3. Ruled out. Content-Type is registered correctly — config/initializers/mime_types.rb maps :docx to application/vnd.openxmlformats-officedocument.wordprocessingml.document, so this is not a mismatched-type warning. Byte-exactness was verified during #7093/#7099 (Content-Length correct, download byte-identical to the stored blob), so it is not truncation in transit.
Which antivirus is producing the warning — Windows Defender, or a third-party product?
Does Chrome or Firefox on the same machine warn too? (Separates the Edge/SmartScreen path from the AV engine itself.)
Does it happen for every org template, or only Montgomery's?
How to Replicate
Not reproducible on macOS or Linux — needs Windows + Edge, and ideally the org's real template rather than the default one (real templates from #6601's comments: prince_george_report_template.docx, montgomery_report_template.docx).
Sign in as volunteer1@example.com / 12345678 on a Windows machine using Edge.
Open a case with at least one case contact → Generate court report → pick a date range → Generate report.
Click the resulting download link.
Observe the "virus detected" warning instead of a clean download.
We highly recommend that you join us in slack #casa channel to ask questions quickly. And discord for office hours (currently Tuesday 5-7pm Pacific), stakeholder news, and upcoming new issues.
Reported by Voices for Children Montgomery in the 2026-08-07 stakeholder sync. Distinct from #7093 — see "Not the same bug as #7093" below.
Impacted User Types
Environment
prod. Microsoft Edge on Windows. Downloading a generated court report
.docx.Current Behavior
Generating a court report succeeds, but the browser download is blocked with a "virus detected" warning. The user has to go into their antivirus software and tell it to ignore the detection to download anyway.
Stakeholder's words, from the sync:
Note
Screenshot pending. A redacted screenshot of the Edge warning was captured during the sync and will be attached to this issue.
Expected Behavior
The generated
.docxdownloads without any antivirus or SmartScreen warning.Not the same bug as #7093
#7093 was "the file isn't in the correct format" when opening the report in Word, root-caused to zip64 (#7098, shipped 2026-08-06). This one fires earlier — at download time, in the browser, before Word is involved — and the stakeholder dates it to roughly six months, whereas the zip64 regression only started when the caxlsx bump floated us to rubyzip 3.x in April 2026.
That said, #7098 shipped the day before this was reported, so step one is re-testing: a structurally odd zip (version-needed 45,
0xFFFFFFFFsize placeholders) is exactly the sort of thing antivirus heuristics dislike, so the fix may have taken this with it.Leads, cheapest first
1. The download has no explicit filename — see #7099.
CaseCourtReportsController#show(app/controllers/case_court_reports_controller.rb:22):There is no
filename:, so the browser derives the download name from the URL path. #7093 produced a file named_C-15-JV-24-191.docx— leading underscore, not in the case number. A binary attachment with a browser-derived name, served from a Heroku app domain with no SmartScreen reputation, is a good match for the heuristic profile. Fixing #7099 (File.binread+ explicitfilename:) is the cheapest thing to try and is worth doing regardless.2. Field codes left in the generated document. The org templates are full of Word
MERGEFIELD … \* MERGEFORMATfield instructions — visible in the raw XML ofdefault_report_template.docx, and heavily throughoutmontgomery_report_template.docx(the reporting org's own template). Sablon substitutes the«…»text but the surrounding field-code machinery stays in the package. A.docxcarrying field codes is a classic malware-delivery shape (DDEAUTO / INCLUDEPICTURE), and Defender is aggressive about it. Hypothesis, not verified — worth checking whether the generated output retains field-code remnants, and whether a template stripped of MERGEFIELD instructions downloads cleanly.3. Ruled out. Content-Type is registered correctly —
config/initializers/mime_types.rbmaps:docxtoapplication/vnd.openxmlformats-officedocument.wordprocessingml.document, so this is not a mismatched-type warning. Byte-exactness was verified during #7093/#7099 (Content-Lengthcorrect, download byte-identical to the stored blob), so it is not truncation in transit.Info still needed from the stakeholder
How to Replicate
Not reproducible on macOS or Linux — needs Windows + Edge, and ideally the org's real template rather than the default one (real templates from #6601's comments:
prince_george_report_template.docx,montgomery_report_template.docx).volunteer1@example.com/12345678on a Windows machine using Edge.How to access the QA site
Login Details:
Link to QA site
Login Emails:
/all_casa_admins/sign_inpassword for all users: 12345678
Questions? Join Slack!
We highly recommend that you join us in slack #casa channel to ask questions quickly. And discord for office hours (currently Tuesday 5-7pm Pacific), stakeholder news, and upcoming new issues.