Closed WillLP-code closed 1 year ago
It's probable that the locations are not flagged because they are pushed to the CINdetailsID column which does not exist in the user interface. We created it for internal processes only.
Pushing the error locations to the LAchildID column should fix this bug. The outer join works.
The errors came from the fact that assessments was brought in as CINdetails not assessments so it compared the wrong tables
Isn't this join still wrong? (Can't flag in PR because not changed so below is current main)
Isn't this join still wrong? (Can't flag in PR because not changed so below is current main)
@SLornieCYC I think it is wrong, but, and this is funny I suppose, I don't think it matters as, if the rule points out there's no assessment block, there's no assessment block to highlight even if the row ID is wrong?
Isn't this join still wrong? (Can't flag in PR because not changed so below is current main) https://github.com/data-to-insight/CIN-validator/blob/dc4559d2362e0efacfe47ebb9b4b3d538c7d0094/cin_validator/rules/cin2022_23/rule_2991Q.py#L52-L57
@SLornieCYC I think it is wrong, but, and this is funny I suppose, I don't think it matters as, if the rule points out there's no assessment block, there's no assessment block to highlight even if the row ID is wrong?
That is, in fact, funny. It simply slipped through the cracks of the logic. Still, worth changing.
Nice. Thanks, Will.
I was just about to ask about your changes to fake data too. Then you reversed it. All good.
closes #376
Assessments was set to CINtable.CINdetails instead of assessments. Also, the merge used was outer instead of left. Before the fix, the bug can could recreated by using CIN_census_2021 and removing the assessments block, an assessments block was still made.