114 and 104 fixes

[ri-pandey]

Description

The SearchAndSelect widget wasn't tested with the Project-Datasets pagination code. This PR adds the fixes adds the fixes necessary for that.

Related Issue(s)

Closes #104 and #114

If applicable, please reference the issue(s) that this PR addresses. If the PR does not address any specific issue, you can remove this section.

Changes Made

List the main changes made in this PR. Be as specific as possible.

• [x] Feature added
• [x] Bug fixed
• [x] Code refactored
• [x] Other changes: [describe]

I updated the DatasetSelect widget so that it only returns datasets that match a search if the current user is permitted to see the list of datasets assigned to the project (i.e., if user has an association for this project). Without this we would be running into cases where an operator cannot see the list of datasets assigned to a project, but they can still search for datasets in the DatasetSelect widget, and thereby see which datasets are assigned to this project. For this, the /datasets/ endpoint now checks for project-user association, if a project_id param is included in the query. If the param is included, and the requester does not have an association for the project, the /datasets/ endpoint returns an empty array, which results in the DatasetSelect not showing any options to choose from.

I also added an API endpoint to get a list of datasets assigned to the given project. This is used to determine which datasets should have a + / - icon next to them in the DatasetSelect widget (previously we were relying on the datasets stored inside projectFormStore to determine this, which we can't do anymore, since we now fetch datasets in batches for the pagination). This endpoint also only returns datasets belonging to a project if the requester has an association with the given project.

I also modified the projects/:id/datasets endpoint so that it doesn't drop all datasets before creating new associations for all of them (original behavior). Instead the endpoint now takes a list of add_dataset_ids and remove_dataset_ids. These list of datasets are added/removed in one transaction. I also changed this endpoint from PUT to PATCH since it seemed more appropriate.

Furthermore, the ProjectDatasetsTable now re-triggers datasets' retrieval when datasets are added/removed via the SearchAndSelect widget.

I also made a change where we are no longer storing the paginated project-datasets inside projectFormStore, and instead storing them in the local state of ProjectDatasetsTable (other places in the codebase that were using the projectFormStore are not affected). While this isn't strictly necessary, I decided to stick with this change.

Finally, I fixed the DatasetSelect widget in CreateProjectStepper so that it now functions with the updated DatasetSelect.

The endpoints that I have modified should have all of their usages throughout the app accounted for.

Here is an updated review of how the Project-Datasets pagination and the DatasetSelect work based on different roles:

1. Role user User can see datasets assigned to a project only if the user has an association for the project. They do not have the option to open the DatasetSelect widget.
2. Role operator operator can see datasets assigned to a project only if the operator has an association for the project. They will see the option to open the DatasetSelect widget, which will also only show results if the operator has an association for the project.
3. Role admin same as operator

All the other changes in the PR are from reverting and then re-reverting tickets #104 and #114, meaning that those changes have already reviewed.

Checklist

Before submitting this PR, please make sure that:

• [x] Your code passes linting and coding style checks.
• [x] Documentation has been updated to reflect the changes.
• [x] You have reviewed your own code and resolved any merge conflicts.
• [x] You have requested a review from at least one team member.
• [x] Any relevant issue(s) have been linked to this PR.

[ri-pandey]

@deepakduggirala I have undone the access-control constraints that I outlined above, and updated the code based on our talk yesterday. Here is an updated description:

1. User roles can only open projects assigned to them, and read but not edit the project-dataset associations on those projects.
2. Operator and admin roles can open any projects, and read as well as edit the project-dataset associations of any project.

In ticket #104 we introduced the constraint of checking for project-user association before fetching project-dataset associations, which is not necessary. I have removed this change, so that operators and admins can see project-dataset associations regardless of whether or not they are associated with the project. The constraint of user role only being able to call this endpoint for projects owned by them is still in place.