Senior Housing Preference Filter

[avaleske]

Blocked by how we're going to store senior housing preference or restriction data. (Ask @anders-schneider)

Should this support filtering to places that have a preference OR a restriction?

[avaleske]

@anders-schneider assigning to you for senior preference/restriction questions

[willrlin]

@anders-schneider do you have an update on this?

[anders-schneider]

Nope; I have a question out to HRD that I just bumped.

[willrlin]

Note to self: this question is another question regarding what the spreadsheet column "Elderly=TRUE" means for the property.

[willrlin]

Assumption to unblock the work: filter on the reserved community type first, think about how much work it would be to include preference in the filter as an OR.

[avaleske]

Another note on this that @elenm and I ran into yesterday as she was working on this: We weren't sure if it's possible for a listing to have multiple reserved community types. That is, could a listing be both Senior and Disabled?

If so, we realized that allowing people to search only for listings with multiple reserved community types (So "Senior AND Disabled" vs "Senior and/or Disabled") would require additional work in how we build the filter query. In the inner query, we'd to filter only to listings that have rows for both community types. If a listing only had one of them, it would need to be excluded somehow (probably by joining the reserved community type table on the listing a second time and checking the first for Senior and the second for Disabled, if that didn't blow up the number of rows too much)

Also, when it comes to implementing this, we noticed a few options (and went with the first one):

• The approach Elen started on that seems the most flexible: Add a new "seniorHousing" filter type that takes a boolean (so we can search for "not senior housing" as well). This then requires adding a custom filter handler in addFilters() to handle building a WHERE clause from the boolean, similar to what I started to do for bedrooms in this commit (diff) when I thought it was going to need to be a custom filter. It could just use the NA comparison type since it's gonna ignore the comparison anyway.
• Have a filter called something like "reservedCommunityType" that takes an enum for which community type we're going to use. While this has the benefit of probably letting us use the generic filter handler that's already in addFilters(), Elen noted that this wouldn't let us search for "not senior housing", which is something you'll want to do if you're under the age cutoff.

[avaleske]

Also, hmm... if a listing can have multiple community types the simple "don't show me listings that are seniors only" won't work, because it will just filter out the rows where the listing is "Seniors" but not the rows where that listing is "Disabled" and so it will still show up in the results. If a listing can only have one community type this isn't a problem.

[anders-schneider]

I think Elen has work in flight on this - I'm going to unassign (but @elenm I'm down to pair on this when you're back!)

[elenm]

Are front end modal changes in scope for this ticket?

Also regarding our discussion with Austin about multiple community types per property, I've decided to assume that there will only be a single community type per property until we know for sure there need to be multiple.

[willrlin]

Yes, I think this covers everything to get the filter working for a user on /listings, not via the eligibility questionnaire (frontend changes, plus any backend filter changes, but I think you were adding the backend portion in another PR).

[willrlin]

Closed by #471