Repository navigation
Keep the workspace member Role page working right after inviting a member #103855
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
0a55551
da2f0de
3fbc4f5
35b9afd
fec9308
5f0aaba
46de57a
20e2616
264b64b
ec9a984
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| import {getMemberLoginByAccountID} from '@libs/WorkArrangementUtils'; | ||
|
|
||
| import type {PersonalDetails, PersonalDetailsList, Policy} from '@src/types/onyx'; | ||
|
|
||
| import type {OnyxEntry} from 'react-native-onyx'; | ||
|
|
||
| import usePersonalDetailByLogin from './usePersonalDetailByLogin'; | ||
|
|
||
| type WorkspaceMemberFromRoute = { | ||
| /** The member's login, empty when the member can't be resolved */ | ||
| memberLogin: string; | ||
|
|
||
| /** The member's personal details, looked up by login so they survive the optimistic accountID swap */ | ||
| memberPersonalDetails: PersonalDetails | undefined; | ||
|
|
||
| /** The member's current accountID, which differs from the route's once the invite request finishes */ | ||
| accountID: number; | ||
| }; | ||
|
|
||
| /** | ||
| * Resolves the workspace member a member page was opened for. The route may hold the optimistic accountID of a member | ||
| * who was just invited, which stops matching personal details once the backend supplies the real one, so the member | ||
| * is resolved by login instead. | ||
| */ | ||
| function useWorkspaceMemberFromRoute(policy: OnyxEntry<Policy>, personalDetails: OnyxEntry<PersonalDetailsList>, routeAccountID: number): WorkspaceMemberFromRoute { | ||
| const memberLogin = personalDetails?.[routeAccountID]?.login ?? getMemberLoginByAccountID(policy, routeAccountID); | ||
| const memberPersonalDetails = usePersonalDetailByLogin(memberLogin); | ||
| const accountID = memberPersonalDetails?.accountID ?? routeAccountID; | ||
|
|
||
| return {memberLogin, memberPersonalDetails, accountID}; | ||
| } | ||
|
|
||
| export default useWorkspaceMemberFromRoute; |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,6 +5,7 @@ import type {ListItemType} from '@components/WorkspaceMemberRoleList'; | |
| import useCurrentUserPersonalDetails from '@hooks/useCurrentUserPersonalDetails'; | ||
| import useRedirectSubmitWorkspaceFeatureUpgrade from '@hooks/useRedirectSubmitWorkspaceFeatureUpgrade'; | ||
| import useRuleBotGuardModal from '@hooks/useRuleBotGuardModal'; | ||
| import useWorkspaceMemberFromRoute from '@hooks/useWorkspaceMemberFromRoute'; | ||
|
|
||
| import {updateWorkspaceMembersRole} from '@libs/actions/Policy/Member'; | ||
| import {isRuleBotEnforcingRules} from '@libs/AgentRulesUtils'; | ||
|
|
@@ -33,19 +34,21 @@ type WorkspaceMemberDetailsRolePageProps = Omit<WithPolicyAndFullscreenLoadingPr | |
| }; | ||
|
|
||
| function WorkspaceMemberDetailsRolePage({policy, personalDetails, route}: WorkspaceMemberDetailsRolePageProps) { | ||
| const accountID = Number(route.params.accountID); | ||
| const routeAccountID = Number(route.params.accountID); | ||
| const policyID = route.params.policyID; | ||
| const showRuleBotGuardModal = useRuleBotGuardModal(); | ||
| const {login: currentUserLogin = ''} = useCurrentUserPersonalDetails(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ❌ CONSISTENCY-3 (docs)This three-line member-resolution block — Extract the block into a single shared hook in const {memberLogin, accountID} = useWorkspaceMemberFromRoute(policy, personalDetails, routeAccountID);Reviewed at: 35b9afd | Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed in 5f0aaba. I moved the block into a new hook, |
||
| const memberLogin = personalDetails?.[accountID]?.login ?? ''; | ||
| const {memberLogin, accountID} = useWorkspaceMemberFromRoute(policy, personalDetails, routeAccountID); | ||
| const member = policy?.employeeList?.[memberLogin]; | ||
| const canManageSelectedMemberRole = canMemberAssignRole(policy, currentUserLogin, member?.role); | ||
| // The Authorized Payer (reimburser) must stay a valid payer, so restrict them to the roles that can pay (for example Admin or Payments Admin). | ||
| const isReimburser = isPolicyReimburser(policy, memberLogin); | ||
| const allowedRoles = getAllowedRolesForMember(policy, memberLogin); | ||
| // Go back with the route's accountID so it matches the details screen below, which keeps the optimistic accountID it was opened with. | ||
| const memberDetailsRoute = ROUTES.WORKSPACE_MEMBER_DETAILS.getRoute(policyID, routeAccountID); | ||
| useRedirectSubmitWorkspaceFeatureUpgrade({ | ||
| policy, | ||
| backTo: ROUTES.WORKSPACE_MEMBER_DETAILS.getRoute(policyID, accountID), | ||
| backTo: memberDetailsRoute, | ||
| upgradeFeatureAlias: CONST.UPGRADE_FEATURE_INTRO_MAPPING.roles.alias, | ||
| }); | ||
|
|
||
|
|
@@ -65,7 +68,7 @@ function WorkspaceMemberDetailsRolePage({policy, personalDetails, route}: Worksp | |
| return; | ||
| } | ||
| updateWorkspaceMembersRole(policy, [memberLogin], [accountID], value); | ||
| Navigation.goBack(ROUTES.WORKSPACE_MEMBER_DETAILS.getRoute(policyID, accountID)); | ||
| Navigation.goBack(memberDetailsRoute); | ||
| }; | ||
|
|
||
| return ( | ||
|
|
@@ -84,7 +87,7 @@ function WorkspaceMemberDetailsRolePage({policy, personalDetails, route}: Worksp | |
| policy={policy} | ||
| onSelectRole={changeRole} | ||
| allowedRoles={allowedRoles} | ||
| navigateBackTo={ROUTES.WORKSPACE_MEMBER_DETAILS.getRoute(policyID, accountID)} | ||
| navigateBackTo={memberDetailsRoute} | ||
| /> | ||
| </ScreenWrapper> | ||
| </AccessOrNotFoundWrapper> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file ships two behavior changes that no test exercises:
navigateBackToDetailsnow goes back withrouteAccountID(the stale optimistic id) instead ofmemberAccountID(line 87).setEmployeeWorkArrangementis now called with the resolved realaccountIDinstead ofmemberAccountID(line 99).Both mirror the Role-page fix, which has solid coverage in the new
WorkspaceMemberDetailsRolePageTest. Please add an equivalent test for the Work arrangement flow under a stale optimisticaccountID. It should assert that:setEmployeeWorkArrangementreceives the real account id.goBacktargets the details route built with the stale id, so it returns to the existing details screen instead of stacking a new one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 20e2616.
main'sWorkArrangementPageTestalready covers both cases with an optimistic accountID that swaps to a synced one:uses the resolved account ID for the first arrangement change after an offline invite syncschecks thatsetEmployeeWorkArrangementreceives the real accountID.All 33 tests across the four member-page suites pass.