fix: optimise users query frontend and backend#1369
fix: optimise users query frontend and backend#1369yoganandaness wants to merge 5 commits intodevelopfrom
Conversation
yoganandaness
requested review from
EdwardHaynes
and removed request for
a team
yoganandaness
force-pushed
the
SWAP-5236-uo-search-user-by-email
branch
from
506f41b to
a135e98
Compare
| } | ||
|
|
||
| @Authorized() | ||
| @Authorized([ |
There was a problem hiding this comment.
question: I was wonder what is the reason of adding this? I think the least permissive one is the USER. we also add now PROPOSAL_READER, so we would need to remember adding it here as well as for all the future roles. Do you want to exclude a role here?
|
|
||
| @Authorized() | ||
| @Authorized([Roles.USER_OFFICER]) | ||
| async getPreviousCollaborators( |
There was a problem hiding this comment.
breaking: I think this is used in participant selector and needed for the USER role as well
There was a problem hiding this comment.
My Mistake. Thanks a lot.
| userRole?: UserRole, | ||
| subtractUsers?: [number] | ||
| ) { | ||
| if (!agent) { |
There was a problem hiding this comment.
suggestion: I tink we normally mark agent with "!" if there is @Authorized abobe the function, as for some reason TS can not infer that the agent must be defined. Or i wonder can you just change 146 and remove the null ? Not a strong oppinion here just observation.
There was a problem hiding this comment.
Shall we take this to a separate improvement? I see some potential fix to this overall. @jekabs-karklins
| title={t('instrumentSci')} | ||
| invitationUserRole={UserRole.INSTRUMENT_SCIENTIST} | ||
| /> | ||
| {isUserOfficer && ( |
There was a problem hiding this comment.
question: What happens if this condition is not in place?
There was a problem hiding this comment.
The Technique page is currently accessible only to the User Officer. Check here.
The PeopleSelectorModal is the generic modal, that is used to assign people to different entities including Technique. Since the Technique - Scientist assignment is a User Officer's only role, I thought to add this condition, so that other Role can't access this, if this component is used in the future
This is just a frontend condition and doesn't add a lot of value, other than self-documentation.
Let me know if you would like to remove this.
…re into SWAP-5236-uo-search-user-by-email
| title={t('instrumentSci')} | ||
| invitationUserRole={UserRole.INSTRUMENT_SCIENTIST} | ||
| /> | ||
| {isUserOfficer && ( |
2 participants
Description
This PR introduces a refactor and consolidation of user and participant selection components across the frontend, along with backend enhancements to user search and access control.
Motivation and Context
The participant selection logic had diverged over time, with multiple overlapping components and proposal-specific variations. This increased cognitive load, duplicated logic, and made future changes error-prone.
This refactor consolidates participant selection into clearer, reusable components, improving maintainability and consistency across the application. Removing legacy components and unused props reduces technical debt and simplifies the codebase.
On the backend, expanding search fields improves administrative and user workflows when locating users. Tightening access control and removing reliance on externally provided
userIdparameters strengthens security by ensuring queries are scoped to the authenticated agent context.How Has This Been Tested
Manually
Fixes
N/A
Changes
ProposalParticipantLegacy.tsxand eliminated unused props and proposal-specific modal logic.emailandoidc_sub.getPreviousCollaboratorsto useagent.idand guard against missing agent.Depends on
None.
Tests included/Docs Updated?