non-competes ¶
related to CATS-759 and CATS-769
overview ¶
Need to provide a mechanism for dr users to add multiple addresses. The addresses represent
- previous place of employment
- date(s) of non-compete
- radius for non-compete
Hospital addresses that fall within the radius of one or more existing ‘non compete addresses’ will be noted in the vet portal screens.
data ¶
‘non-compete’ will just be an address entry with some additional metadata embedded. addresses are already related to users - unsure there’s a need to create a ‘non-compete’ top level model just to hold an address and user relation. The ‘type’ and metadata should be able to provide enough functionality.
issues ¶
address types ¶
Address table has an existing ‘type’ column, but it’s not been used much yet. The system will need to be audited for current uses where type is not specified, then updated to look for ‘null’ type (or… null type converted to some string type).
New type will need to be added - ‘non-compete’ type - and be linked to users via address_user table.
metadata ¶
We can add the ‘non-compete’ information to the metadata column in the ‘addresses’ table (via ‘metadata’ trait on the address object).
distance calculations ¶
Distance calculations will need to be run, but we should avoid hitting mapbox. We’ve been assured we can get by with an estimate number, which we can calculate from lat/lon alone.
Adding –skip-over-estimate and –estimate-only flags on calculate distance.
overlap matches ¶
During pull of all sites and addresses for a vetportal shifts pull, we can also grab all the non-compete address types for the given user, then iterate through the matching lat/lon intersections. We can then add data to the shift object (on the php side) before serializing and sending down to JS. The vet portal JS will need to be updated to show the conflicting non-compete info.
Matching may be faster to pull a count of the non-compete addresses against the site addresses with mileage X…
Unsure how adding new hospital sites impacts this.