search

abtassociates / eva

Eva is a HUD application to aid HMIS Leads with data analysis. It is an open-source project intended for local use by HMIS Administrators in Continuums of Care (CoCs) around the U.S. and its territories.
GNU Affero General Public License v3.0
14 stars 4 forks source link

make datedeleted HP. Now that we're filtering out rows where datedele… #483

Closed alex-silverman closed 3 months ago

alex-silverman commented 5 months ago

…ted is non-null, if the column is missing, Eva will crash

kiadso commented 4 months ago

@alex-silverman I looked at the testing and I'm not understanding why it's failing. It says it's in the missing-files check but I see no difference in the images. There are also several other "new" images, but they're not different..

alex-silverman commented 4 months ago

I finally may have figured out how to fix the all-files-needing-to-be-committed thing:

"These changes mean that metadata about your file changed, however the content of your file did not."

I ran the system() one at the bottom and it got rid of the files in my Git window!!!

I will say, after reading a bit more, I understand this a bit better, and the above may not be the best solution. It sounds like 100755 (or just 755) means the file is executable. 100644 (or just 644) means it's read/write only. Most files should NOT be executable. I'm not sure how they BECAME 755 (I guess it's common when working across different platforms (Windows, macOS, Linux) due to how Git handles file permissions), but I don't think we want them to be, for security reasons. the git config command above tells git to ignore file modifications, which means we may not see when files change permissions for some reason. I don't think it matters much, but seems better to know. It looks like you can remove the executable permission with the following command:

git update-index --chmod=-x <filename>

Or add it with:

git update-index --chmod=+x <filename>

And you can see if it worked with: git ls-files -s <filename>

alex-silverman commented 4 months ago

I think I figured out the issue. You can see the final commit. Basically there was a problem in the way I was restoring the Export file after the test-missing-export script ran (and before the test-missing-multiple-files script ran). I was missing the "row.names = FALSE" argument, which I have in all the other cases. As a result, the restored Export.csv file had an extra column at the beginning with no header, i.e. the index/row names column. That caused the get_col_types function to return "character(0)ccnnnnTT..." or whatever. The problem being that "character(0)" was then being fed to unzip() as a set of column types, c-h-a-r-a-c-t-e-r-(-0-). And since "h" is not a valid character type, it failed there. Not sure why it gave the 404 error it did instead of literally anything more helpful.

My only guess as to why this hadn't come up before is that something changed in the shinytest2 or unzip packages.

Anyway, I've fixed. The only differences I see now are expected - super small file size reductions due to the removed column.