Open m-natarajan opened 1 month ago
Triggered auto assignment to @cead22 (DeployBlockerCash
), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.
Triggered auto assignment to @bfitzexpensify (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
:wave: Friendly reminder that deploy blockers are time-sensitive β± issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
We think that this bug might be related to #wave-collect - Release 1
Job added to Upwork: https://www.upwork.com/jobs/~0110a7f901ae8b6a28
Triggered auto assignment to Contributor-plus team member for initial proposal review - @getusha (External
)
Workspace - "Remove members" and "Make admin" options are present for owner
We allow the select modal to be present for options which have selection disabled. This results in user being able to select rows for which selection has been disabled
We should use isDisabled
and isCheckBoxDisabled
properties here when checking selection mode should be triggered:
if (!turnOnSelectionModeOnLongPress || !isSmallScreenWidth || item?.isDisabled || item?.isCheckBoxDisabled) {
return;
}
This will also fix the issue in WorkspaceTaxesPage
and ReportParticipantsPage
which have the same issue present.
Owner can be selected and there are "Remove members" and "Make members" options which are not applicable to the owner.
We always call onLongPressRow?.(item)
without checking whether that option can be selected or not:
https://github.com/Expensify/App/blob/73f97c930795b4c68512d0e25ee253f7ce7d4515/src/components/SelectionList/BaseListItem.tsx#L75-L77
We should use:
onLongPress={isDisabled || item.isDisabledCheckbox ? undefined : () => onLongPressRow?.(item)}
We can update the condition: https://github.com/Expensify/App/blob/73f97c930795b4c68512d0e25ee253f7ce7d4515/src/components/SelectionListWithModal/index.tsx#L45 to:
if (!turnOnSelectionModeOnLongPress || !isSmallScreenWidth || item?.isDisabled || item.isSelected || item?.isDisabledCheckbox) {
Workspace - "Remove members" and "Make admin" options are present for owner
The problem is that the WorkspaceMembersPage
does not disabled the policy owner option.
Hence, the policy owner option can always be selected and the "Remove members" and "Make admin" options are present for the owner.
We should disable the owner option being able to be selected by adding the following condition, accountID === policy?.ownerAccountID
, to check if the account owns the policy for isDisabled
.
The full condition will look like this.
isDisabled:
accountID === policy?.ownerAccountID
!!details.isOptimisticPersonalDetail ||
(isPolicyAdmin && (policyEmployee.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE || !isEmptyObject(policyEmployee.errors))),
....
@neonbhai why do we need item?.isDisabled
in the condition?
@neonbhai's proposal looks good to me, seems like a very straightforward issue. and we don't want to fully disable it. π π π C+ Reviewed!
Current assignee @cead22 is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.
@getusha Can you re-check the solution, it does not work. We don't have isCheckBoxDisabled
ah I meant to write isDisabledCheckbox
. Solution stays same!
@getusha Can you re-check the https://github.com/Expensify/App/issues/46620#issuecomment-2261675223, it does not work. We don't have isCheckBoxDisabled
Yes, i figured it could be a typio
I don't believe this is just a typo, as the issue appears consistently throughout the entire proposal. Let's have @cead22 review and make a decision on this matter.
In my opinion, it would be more appropriate for other contributors if the selected proposal not only identifies the solution but also ensures it is correctly implemented, rather than rushing to comment (to get the first comment) without proper testing.
I think we should go for the proposals which proposes the idea first. This is noted in https://github.com/Expensify/App/issues/28535 and https://github.com/Expensify/App/issues/27592#issuecomment-1722295827
I agree with @getusha and @neonbhai on this one. I think it's hard to argue that isCheckBoxDisabled
was referring something other than isDisabledCheckbox
Before moving forward with the proposal, what are the use cases for which we should have item.isDisabled
with a value different than item.isDisabledCheckbox
?
what are the use cases for which we should have item.isDisabled with a value different than item.isDisabledCheckbox
we could have this situation if a user was invited to a workspace offline, or if a member is pending delete [ref: here]. But for disabled items, all presses are disabled on the Pressable in BaseListItem
here: https://github.com/Expensify/App/blob/2336ba827e9752d951a322db3a0c61ee40849d8e/src/components/SelectionList/BaseListItem.tsx#L88 so a check for item.isDisabled
is not needed here. We could still add this as a sanity check.
cc: @cead22
π£ @neonbhai π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
Raising PR soon!
@cead22, @bfitzexpensify, @neonbhai, @getusha Eep! 4 days overdue now. Issues have feelings too...
How is this one going @neonbhai?
This issue has not been updated in over 15 days. @cead22, @bfitzexpensify, @neonbhai, @getusha eroding to Monthly issue.
P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!
Seems like automation failed on this one. @cead22 could you please check? thanks!
@bfitzexpensify can you handle payment for this issue please? Automation failed here, but I think @neonbhai should be paid via https://www.upwork.com/jobs/~0110a7f901ae8b6a28, and I'm not sure about @getusha after a brief look at the code
Below is the bug zero checklist for reference, in case we need to complete it. Let me know if I tagged the wrong people on some of the items.
Thanks
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
If you havenβt already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Issue found when validating https://github.com/Expensify/App/pull/45732 Version Number: 9.0.15-4 Reproducible in staging?: y Reproducible in production?: unable to check new feature Issue reported by: applause internal team
Action Performed:
Expected Result:
Owner should not be able to be selected (production behavior).
Actual Result:
Owner can be selected and there are "Remove members" and "Make members" options which are not applicable to the owner.
Workaround:
unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @getusha