search

sfcpc / housing-dashboard

4 stars 0 forks source link

[Schemaless] [PTS Grouping] Associating a PTS group with the multiple parent PPTS records doesn't work #115

Open ilakyapal opened 4 years ago

ilakyapal commented 4 years ago

Right now, when I associate a PTS group to ppts, I look at all the fks in the PTS group, find the first one that has an explicit link to PPTS records, and then treat those PPTS records as the "parent ppts records" for the whole PTS group.

What if another PTS record in the group that has an explicit link to PPTS record refers to a more correct set of PPTS parents? Like a more recent PRJ? Or a newer PRJ that doesnt have some "withdrawn" status?

ilakyapal commented 4 years ago

Should investigate how many cases there are where different permits in the same permit group refer to different PRJs. (I think this should be an infrequent edge case)

May want to spit out a log of how many cases there are like this and tell them to fix it, instead of building in logic to "select the correct" PRJ in the actual UUID assignment.

rajpara11 commented 4 years ago

Just for some follow-up here, it looks like a a not insignificant number of the projects with blank statuses in the dashboard are projects where a group has multiple PPTS parents so one of the PPTS records ends up not pointing to PTS (and it looks like a lot of the times they are PIC projects where there are no ENT records so we end up with no status associated with it).

Don't think we want to fix this in the time we have left, but wanted to call out how it manifests

rajpara11 commented 4 years ago

Some example PRJ's 2019-006163PRJ 2018-012790PRJ 2018-001226PRJ 2017-013651PRJ

rajpara11 commented 4 years ago

Another example is 2000 Bryant which has 2 PRJ's (2013.1865 and 2013.0677). The way this manifests is that when you look up 2013.0677 in Project Lookup in dashboard the project looks like it's not at DBI yet because the permits have been grouped into a different project in our UUID logic

rajpara11 commented 4 years ago

The easiest fix here would be if just the underlying data were cleaned up (i.e. make one PRJ point to another, or just have one root PRJ). If that can't happen, this might become a bit more complicated as the grouping logic would then need to take into account any explicit links (from PRJ's to DBI permits) and maybe not include those in a grouping?