Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
Currently the allow unchecked files action is not working because allowUncheckedFiles()
returns false even though I enabled it. The configuration exported to clamav.settings.yaml was:
enabled: 1
outage_action: '1'
overridden_schemes: { }
scan_mode: '0'
verbosity: 0
....
I think the quotes are messing it up.
Proposed resolution
We should make sure the exported value is an integer.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#5 | 2915237-5-fix_allow_unscanned.patch | 838 bytes | andrewbelcher |
#2 | 2915237-2.patch | 669 bytes | seanB |
Comments
Comment #2
seanBPatch is attached.
Comment #3
RenrhafSame issue encountered, because of a strict comparison "===" between a string "1" and an integer 1 failing.
Patch fixes the issue by converting the string into an integer before the strict comparison.
Comment #4
andrewbelcher CreditAttribution: andrewbelcher at FreelyGive commentedFixing this at the form level isn't really the right approach here. The correct place to make this adjustment is at the schema level, defining the config key as an integer and the schema API will handle the conversion.
However, this will not fix sites which are currently storing as a string, so I would also suggest the strict comparison would be better as a non strict - there's no need for strict as we control what the possible values are and the form API wont support any value combinations where strict would matter.
Will get a patch...
Comment #5
andrewbelcher CreditAttribution: andrewbelcher at FreelyGive commentedHere's a patch that fixes both schema and the comparison.
Comment #6
idebr CreditAttribution: idebr at ezCompany commentedThe schema change fixed config export and the logic in the \Drupal\clamav\Scanner::allowUncheckedFiles().
The config schema is broken in a few other places, so I have raised a followup to fix the remaining errors: #2976304: Fix config schema datatype errors
Comment #8
mcdruidThanks everyone!