Benefit Deletion and API Filtering Issues

[induced]

Issue 1: Unintended Deletion of All Benefits
Description:
When attempting to delete a single benefit from the PMS, all benefits are being deleted instead. This occurs when using the following code snippet:

Code: Select all

for (const benefit of benefitsToDelete) {
    await makeApiRequest('DELETE', `/benefits/${benefit.BenefitNum}`);
}

Expected Behavior:
Only the specified benefit(s) in the benefitsToDelete array should be deleted.

Actual Behavior:
All benefits in the system are being deleted, regardless of the contents of benefitsToDelete.

Questions:
1. Is there a cascading delete set up on the backend that might be triggering this behavior?
2. Are there any triggers or constraints in the database that could be causing this issue?
3. Can you provide logs of the DELETE requests being made and the corresponding database operations?

Issue 2: API Filtering Not Working

Description:
When making GET requests to retrieve specific insPlans, patPlans, Insubs, or other entities with query parameters, the API is returning all records instead of filtering based on the provided parameters.

Expected Behavior:
The API should return only the records that match the query parameters provided in the GET request.

Actual Behavior:
All records are being returned, regardless of the filtering parameters specified in the request.

Questions:

1. Is the API correctly parsing and applying the query parameters?

[SLeon]

Good morning,

Issue 1: Unintended Deletion of All Benefits

The code snippet you shared appears to loop through some list of benefits and calls the Benefits DELETE endpoint each time. The API does not mass delete benefits with this endpoint. All API POST, PUT, and DELETE methods create a SecurityLog entry ("Audit Trail" in the UI) that you can reference.

Issue 2: API Filtering Not Working

The API GET methods only support certain query parameters. These are listed on each resource's page in our documentation. For example, for InsPlans GET (multiple) has two optional parameters: PlanType and CarrierNum. Your screenshot is not using one of these supported filters.

If you need additional parameters not currently supported, you can ask us here to add them to our development list. You can also use our Queries resource, if you would prefer to write your own query.