We are seeing an issue where facilities that have multiple matches (or having many API calls with create=true and match status = pending on the backend) are not completely deleted from the platform and are instead aliased as a different OAR ID (which is created when the original OAR ID is deleted). A user can continue to search for the original OAR ID via the URL and it will be redirected to the newly created OAR ID's URL.
As an example if you search for this facility via the url IN20220746KTGGV you will notice that it redirects to this facility's page: IN2022250HGNBNT. This will continue to happen (we think) until all of the entries that are in match status = pending on the backend are exhausted.
E.g. -
Deleted facility: IN20220746KTGGV
Aliased as: IN2022250HGNBNT
Related to #2019
Technical Notes
The delete endpoint currently uses the following logic:
Delete the FacilityListItem which the Facility was created from, and its linked FacilityMatches
Look for other automatically matched and confirmed match items associated with the Facility, and if a high-quality alternate match exists, create a new Facility from that match. Move all of the matches and list items to the new Facility.
Perform various cleanup tasks
Delete the original Facility
The goal of this behavior is to retain potential high-quality FacilityListItems when deleting a Facility. However, in cases where a single contributor submits a facility dozens or hundreds of times, this results in moderators needing to delete each of those submissions one at a time.
We would like to adjust the logic of the delete endpoint to the following:
Delete the FacilityListItem which the Facility was created from, and its linked FacilityMatches
Delete any linked FacilityListItems and FacilityMatches linked to the Facility and submitted by the same contributor as submitted FacilityListItem which the Facility was created from.
Look for other automatically matched and confirmed match items associated with the Facility but not submitted by the created_from contributor, and if a high-quality alternate match exists, create a new Facility from that match. Move all of the matches and list items to the new Facility.
We are seeing an issue where facilities that have multiple matches (or having many API calls with create=true and match status = pending on the backend) are not completely deleted from the platform and are instead aliased as a different OAR ID (which is created when the original OAR ID is deleted). A user can continue to search for the original OAR ID via the URL and it will be redirected to the newly created OAR ID's URL.
As an example if you search for this facility via the url IN20220746KTGGV you will notice that it redirects to this facility's page: IN2022250HGNBNT. This will continue to happen (we think) until all of the entries that are in match status = pending on the backend are exhausted.
E.g. - Deleted facility: IN20220746KTGGV Aliased as: IN2022250HGNBNT
Related to #2019
Technical Notes
The delete endpoint currently uses the following logic:
The goal of this behavior is to retain potential high-quality FacilityListItems when deleting a Facility. However, in cases where a single contributor submits a facility dozens or hundreds of times, this results in moderators needing to delete each of those submissions one at a time.
We would like to adjust the logic of the delete endpoint to the following:
created_from
contributor, and if a high-quality alternate match exists, create a new Facility from that match. Move all of the matches and list items to the new Facility.