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

Fix fsa checks - to phase2-dev #484

Closed alex-silverman closed 3 months ago

alex-silverman commented 5 months ago

make DateDeleted HP so Eva won't fial if column is missing

alex-silverman commented 4 months ago

@kiadso, the get_col_types function looks identical to me between 484 and 483. What are you seeing that's different?

regarding the conflicts:

  1. helper_functions.R - this one is in the importFile() function. In general, I think we want the stuff from fix_fsa_checks; it's got to remove rows with non-null DateDeleteds, it's formatted better, and it specifies the unzip() package, utils() (I think this becomes relevant because elsewhere in the code I think we use a different package's unzip().) The only thing that's a little less clear is the first bit that checks the extension type. But there, still, I think we want the more generic one from fix_fsa_checks that checks if the upload is NOT a zip file, rather than just checking if it IS a gzip file.
  2. hardcodes.R - this one is that we added a new variable in phase2_dev called all_project_types2. Tbh, I can't find reference to it anywhere else in the phase2_dev code (or math-fixes-g), so maybe we don't need it. But doesn't seem too harmful to keep either.
  3. miny-non-shiny-environment > helper_functions.R - same as #1
  4. custom.css - here, I think we want the code from both branches. The fix_fsa_checks css code is what shows the text that the upload file is being processed when they upload a 2nd file, so they know something is happening. The phase2_dev css makes sure the start and end date ranges are next to each other, rather than stacked, and that the headers look like the others. We may not need the latter, though, since previous CSS code SHOULD take care of syso_header's look. Again, doesn't seem harmful either way