feat: only show calls that are related to techniques assigned to an instrument scientist

[mutambaraf]

Description

This PR improves the filtering of calls related to techniques assigned to an instrument scientist.
Closes: UserOfficeProject/issue-tracker#1518

Motivation and Context

Currently, the Xpress Management page displays all calls with a QUICK_REVIEW status. This PR introduces changes that allow filtering calls based on assigned techniques. Additionally, the "All" filter has been updated to return only proposals with calls relevant to those filters. This ensures instrument scientists only see proposals related to their specific facility and assigned techniques.

Changes

• The filter now checks for call IDs in the callIds array in addition to the callId field.
• This change is implemented in the PostgresProposalDataSource and StfcProposalDataSource classes in the backend, and reflected in the frontend in the ProposalsQuery class and the MenuItems and ProposalMenuListItem components.
• The callIds field is added to the ProposalsFilter class.
• The techniqueProposalUrl is now set to /TechniqueProposals instead of being dependent on the openCall.id.

These changes ensure that only the calls related to techniques assigned to the instrument scientist are displayed, improving the relevance of the displayed data for the user.

How Has This Been Tested?

Fixes Jira Issue

https://jira.esss.lu.se/browse/

Depends On

Tests included/Docs Updated?

• I have added tests to cover my changes.
• All relevant doc has been updated

[Copilot]

Pull request overview

This PR enhances the technique proposal filtering system to show only calls related to techniques assigned to instrument scientists. The implementation adds support for filtering by multiple calls through a new callIds array field, while maintaining backward compatibility with the existing callId field. The PR also simplifies navigation by removing dynamic call-dependent URLs from menu components.

Changes:

• Added callIds array field to ProposalsFilter for multi-call filtering
• Enhanced TechniqueProposalTable to fetch calls based on assigned technique instruments and manage call selection
• Simplified menu navigation by using static URLs instead of dynamic call-based URLs

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
apps/frontend/src/hooks/call/useCallsData.ts	Added skip parameter to conditionally prevent API calls
apps/frontend/src/components/techniqueProposal/TechniqueProposalTable.tsx	Implemented technique-based call filtering, added callIds handling in filter logic
apps/frontend/src/components/menu/ProposalMenuListItem.tsx	Removed dynamic call URL logic, using static /TechniqueProposals path
apps/frontend/src/components/menu/MenuItems.tsx	Removed dynamic call URL logic, using static /TechniqueProposals path
apps/e2e/cypress/e2e/techniqueProposals.cy.ts	Added technique filter visibility check before instrument filter test
apps/backend/src/resolvers/queries/ProposalsQuery.ts	Added callIds field to ProposalsFilter GraphQL type
apps/backend/src/datasources/stfc/StfcProposalDataSource.ts	Updated query to merge callId and callIds for filtering
apps/backend/src/datasources/postgres/ProposalDataSource.ts	Updated queries to merge callId and callIds for filtering
apps/backend/src/datasources/postgres/CallDataSource.ts	Added table prefix to call_id in fieldMap for unambiguous sorting

Comments suppressed due to low confidence (1)

apps/frontend/src/components/techniqueProposal/TechniqueProposalTable.tsx:832

• The else branch assumes filter.callId is always a valid number, but the ProposalsFilter type allows callId to be number or undefined or null. While the CallFilter component ensures it always passes either 0 or a valid number, this code is fragile and could break if handleFilterChange is called from other contexts. Consider adding a guard to check if filter.callId is a valid number before adding it to the array, such as: else if (filter.callId) { updatedFilter.callIds = [filter.callId]; }

    } else {
      updatedFilter.callIds = [filter.callId as number];
    }

[yoganandaness]

If we are going to have callIds, will it make sense to remove the callId?

[mutambaraf]

I can do it but just wanted to maintain backward compatibility because l saw so many places it is being used.

[yoganandaness]

Any specific reason to this? If important, should the sort_order also be call.sort_order?

[mutambaraf]

It will not be necessary because , only added that because call_has_instruments has also a call_id and the database was complaining because of this being ambiguous .It was broken but looks like we never sent instruments as part of filters.

[yoganandaness]

I feel, there should be an Authorizer in the backend that validates the callIds and decide if they are associated with the Instrument Scientists through the Technique. Else, it will be easy to manipulate the graphql query to pass the callIds, that are not associated and get unauthorized access.

Also would be worth to check if the PR already solved this use case

[mutambaraf]

We have not started implementing the PR for it to work with our current environment and we have a very short time to release for LSF Xpress. For Authorizer, we already have have one here @Authorized([Roles.INSTRUMENT_SCIENTIST, Roles.USER_OFFICER]) on getTechniqueScientistProposals . These are only filter values on what the user already have access to we are just being more explicitly that we only need proposals associated with these call ids instead of all of them.