text:
[$500] Bank account - On selecting "I accept expensify terms", error not displayed for "Account number"

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Version Number: 1.4.33
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4251914
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Go to https://staging.new.expensify.com/
Tap profile icon
Tap workspaces--- Workspace
Tap Bank Account
Tap Connect manually
Select "I accept expensify terms"

Expected Result:
When user select "I accept expensify terms", error must be displayed for both "Routing number" & "Account number"
Actual Result:
Error displayed for "Routing number" but not shown for "Account number" when user select "I accept expensify terms".
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[x] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/cb3c8d6c-beb9-47e3-b651-e4d538f54300
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019df4e12cd288976c
Upwork Job ID: 1752123886122000384
Last Price Increase: 2024-01-30

We only show errors for fields that are touched, since the first one is focused it's marked as touched.
The account number is never touched so it won't show the error yet.

Agreed. This is not a bug.

Hm, but if the user clicks out of the routing number field, we will still show an error there, no?

Hm, personally I think this is fine and not worth changing anything now.

Hm, but if the user clicks out of the routing number field, we will still show an error there, no?

@joekaufmanexpensify Yes, if the user proactively blurs the routing number field, it will still show an error and blur the routing number input.
But on native Android/iOS if we toggle the checkbox, the input won't be blurred and no error will show, I think that makes more sense (allowing the users to continue to type on the inputs right after the user toggles the checkbox, less manual action from user) and we should do the same for mWeb/web.

Based on what you shared I actually think native has a bug to not trigger the validation.
If they follow the order of the list as we present it to the user:

fill out account number
tap Routing, and account number gets validated
fill out routing number incorrectly
tap 'i accept term'
here it should validate the routing number
So that I can be informed of whether or not I can 'Continue'

I'm not sure I understand the report. If you follow the 4 steps you listed above we do throw an incorrect routing number error.

I'm not sure I understand the report. If you follow the 4 steps you listed above we do throw an incorrect routing number error.

The report is describing how I think it should be behaving, which is how web is handling!
However if you look at the video from https://github.com/Expensify/App/issues/35345#issuecomment-1917227581 they actually demonstrate this being broken in native. Since clicking I accept does not trigger validation.


text:
[HOLD for payment 2024-05-22] [HOLD for payment 2024-05-20] [HelpDot] Link this issue to auto assign Rushat for a review.

When creating a PR, link this issue so that I'm auto assigned for a review.
Issue OwnerCurrent Issue Owner: @JmillsExpensify

@lschurr you may unassign to avoid pings

@maddylewis could you please assign me this issue

@JmillsExpensify I think payment happens in the separate payment issues and the automation is incorrect here.

Checking what's going on with this on in slack

@garrettmknight this is the issue for payment - https://github.com/Expensify/App/issues/32825
It has the necessary payment details

This issue is created only for the purpose of auto-assigning me for reviews.

Ok cool. I'm going to close this issue then.

I think I'm getting all PR reviews assigned me to because I am assigned on this GH 🤔. That isn't necessarily a problem, but I do think it'd be better to round-robin the reviews via PullerBear so I'm going to unassign.

@amyevans could you please reopen the issue

Why can't it rely on PullerBear? 😄

does it work on closed issues?

I think it will just assign a random internal engineer on the PR review (according to PullerBear logic, which is based on lowest number of reviews), but if it ends up not working we can reassess!

not a bug, no checklist needed.
Is this issue complete? It is not showing up in my K2; I just got an email about it to check in.
I think the Expensify Help stuff is still going on, right?

source: gharchive/issue

authors: JmillsExpensify amyevans dangrous garrettmknight rushatgabhane

repo: Expensify/App

license: MIT

license_type: permissive

license_source: github-api


text:
[Payment card / Subscription] Implement - Integrate 3ds flow with Backend data

Design doc
Issue OwnerCurrent Issue Owner: @waterim

Hi, I'm Eugene from Callstack - an expert agency - and I would like to work on this issue.

Not yet ready for work

Reassigning to @blimpich since I'm headed out on extended leave after today

@waterim you're combining this issue with https://github.com/Expensify/App/issues/42432 right? Can you comment so we can assign you here to track.

Hello, yes, Im combining this issue with UI issue!

Add @Pujan92 as they are reviewing the PR

Shall we just close this issue, as we're building it in one PR and we can use this issue: https://github.com/Expensify/App/issues/42432

Yes, lets do that for sake of simplicity.

authors: amyevans blimpich pasyukevich trjExpensify waterim


text:
[HOLD for payment 2024-07-10] Android & iOS - Tags - "Enabled" badge is not crossed out when tag is deleted offline

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Version Number: 1.4.76-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4578912
Issue reported by: Applause - Internal Team
Action Performed:

Launch New Expensify app
Go to workspace settings
Go to Tags
Add a tag if there is no tag
Go offline
Delete the tag

Expected Result:
The "Enabled" badge will be crossed out when tag is deleted offline (web behavior)
Actual Result:
The "Enabled" badge is not crossed out when tag is deleted offline
This issue also applies to categories, distance rates and tax rates
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/dcd0e5b0-83c7-432e-8a93-9445718ef359
View all open jobs on GitHub
Issue OwnerCurrent Issue Owner: @JmillsExpensify

@JmillsExpensify  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

We think that this bug might be related to #wave-collect - Release 1

Proposal
Please re-state the problem that we are trying to solve in this issue.
Enabled badge of the right component is not crossed out when deleting a tag while offline.
What is the root cause of that problem?
The crossed out style is applied from OfflineWithFeedback. OfflineWithFeedback will give the component a deleted style.
https://github.com/Expensify/App/blob/2514f2988eb26858d30fa501c0040b1f8fc2e239/src/components/OfflineWithFeedback.tsx#L116-L118
However, the Enabled badge component itself doesn't accept any style props.
https://github.com/Expensify/App/blob/2514f2988eb26858d30fa501c0040b1f8fc2e239/src/components/SelectionList/ListItemRightCaretWithLabel.tsx#L14
So, the deleted style is never applied to it.
What changes do you think we should make in order to solve the problem?

Add a style prop to ListItemRightCaretWithLabel and append it to the label text style here.
https://github.com/Expensify/App/blob/2514f2988eb26858d30fa501c0040b1f8fc2e239/src/components/SelectionList/ListItemRightCaretWithLabel.tsx#L20

Opening up to the community.

Still waiting for proposal review. cc @DylanDylann

This issue only reproduces on the native app. I think the RCA will be more complicated than the above proposals

However, the children recursive search logic will not work in case the Text is nested inside another custom component like the Badge here. In this case, when iterating here, the children of Badge element will be undefined, because children only works for elements directly exposed inside the children of OfflineWithFeedback.tsx. This leads to the Text (a child in Badge structure) not having the strike-through style applied.

@tienifr Thanks for this point. But it is still grey to me, I will need some time to dive deep into this problem. It would be great if you could detail more

Issue not reproducible during KI retests. (First week)

@mvtglobally I still reproduce on IOS

Update: I am still deep diving into @tienifr's proposal. This bug is specific to native device

@Krishna2323 @bernhardoj Your RCA isn't correct to me because we implement the recursive logic to apply strike-through to child components (read @tienifr's proposal for more detail)

@tienifr Thanks for your detail. But It is still grey to me.  In TableListItem Component, we still TextWithTooltip (it is a custom component) but it still be greyed out

I would prefer @tienifr's proposal. Let's go with them

@tienifr mind filling out the BZ checklist? I confirm the $250 payment summary above is correct for both contributors.

@DylanDylann shall I create an Upwork job/contract for you?

@JmillsExpensify Yes please!

@DylanDylann offer sent!

Reminder on the Upwork contract!

@JmillsExpensify Sure thing, I accepted the offer, TY

All paid out! @tienifr I'm going to close this issue for now, though before you submit an expense via New Expensify, please make sure to complete the BZ checklist.

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:
[@DylanDylann] The PR that introduced the bug has been identified. Link to the PR: NA
[@DylanDylann] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: NA
[@DylanDylann] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: NA
[@DylanDylann] Determine if we should create a regression test for this bug. Yes
[@DylanDylann] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
Regression Test Proposal

Go to workspace settings
Go to Tags
Add several tags if there is no tag
Go offline
Delete the tags
Verify the tag and "Enabled" badge will be crossed out when the tag is deleted offline
Go online
Verify the tags disappear

Do we agree 👍 or 👎

Ah thanks! I'll re-open this one.

@mallenexpensify would you mind double-confirming payment summary before I approve payment?

Contributor: @DylanDylann paid $250 via Upwork
Contributor+: @tienifr owed $250 via NewDot

$250 approved for @tienifr

authors: DylanDylann JmillsExpensify bernhardoj lanitochka17 mallenexpensify mvtglobally


text:
[$250] Unable to load chats and continuous loading appears

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Version Number: 1.4.81-1
Reproducible in staging?: need reproduction
Reproducible in production?: need reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @davidcardoza
Slack conversation:
https://expensify.slack.com/archives/C049HHMV9SM/p1718027588707529 and https://expensify.slack.com/archives/C05LX9D6E07/p1718026564489519
Action Performed:

Open the staging app from the TestFlight

Expected Result:
Chats should be loading
Actual Result:
infinite loading appears
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[x] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/Expensify/App/assets/38435837/a5974e1e-f9e0-4907-9e35-84861ee56a55

https://www.expensify.com/_devportal/tools/logSearch/#query=request_id:("8919b878fae44188-LHR")+AND+timestamp:[2024-06-10T12:31:14.825Z+TO+2024-06-10T14:31:14.825Z]&index=logs_expensify-028863
logs-2024-06-10 13_35_46.937 (1).txt
App_Info_1.4.79-11 (1).json
Profile_trace_for_1.4.79-11 (1).cpuprofile
https://github.com/Expensify/App/assets/38435837/55e0dde2-0083-45c8-8fa0-9ffdb9826f87

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01b75a1eb219ec6562
Upwork Job ID: 1801371992691489778
Last Price Increase: 2024-06-13

Issue OwnerCurrent Issue Owner: @rojiphil

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

We are removing all AMs as admins from workspaces - I think that might be the fix.  We'll test again once that is complete.

This has been spotty - let's see if it can get reproduced in the next couple of weeks.

moving to weekly to correspond with testing

I'm still not able to reproduce this - closing

authors: MelvinBot m-natarajan slafortune


text:
[$250] Invoice - Default workspace avatar is displayed for invoice receiver when it has custom avatar

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Version Number: v9.0.26-5
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/4864174
Email or phone of affected tester (no customers): applausetester+kh050806@applause.expensifail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team
Action Performed:
Precondition:

Workspace has custom avatar.

Go to staging.new.expensify.com
Go to FAB > Send invoice.
Enter amount. select user and send invoice.
As invoice receiver, go to invoice chat.

Expected Result:
Invoice receiver should be able to see the custom workspace avatar.
Actual Result:
Invoice receiver is unable to see the custom workspace avatar. It shows the default avatar instead.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/3c05b551-6bf5-4305-a2a9-38bc189d0262

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~014c6b9826c08600f4
Upwork Job ID: 1830746639785190043
Last Price Increase: 2024-09-02

Issue OwnerCurrent Issue Owner: @Pujan92

We think this issue might be related to the #vip-bills

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

Unable to reproduce, throwing a retest on here

I tested on v9.0.26-6 and this issue was reported with Version Number: v9.0.26-5
@Nodebrute , can you outline your reproduction steps? Reckon one of us is doing something different than the other.

Proposal
Please re-state the problem that we are trying to solve in this issue.
Default WS avatar is displayed in invoice room if the user isn't part of the workspace.
What is the root cause of that problem?
When user A sends an invoice to user B from a workspace that user B is not a member of, the policy data will be undefined. When we are trying to get the workspace icon,
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/libs/ReportUtils.ts#L2246-L2250
we already prioritize the avatar from report.policyAvatar. However, the icon is still wrong and it happens after we introduce the caching in https://github.com/Expensify/App/pull/46886.
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/libs/ReportUtils.ts#L1937-L1948
The caching somehow saves the default avatar for the workspace. Here is the logic to decide whether we can get the avatar from the cache or need to save it to the cache or not.
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/libs/ReportUtils.ts#L1925-L1934
The first condition is of course to make sure the cache exists. Second, it checks whether the cached image source and the policy avatar source are the same or not. We will focus on the second condition.
As mentioned above, if the user isn't part of the WS, then the policy data will be undefined, so, the avatarURL is undefined (because we don't use report.policyAvatar here) and the isSameAvatarURL condition is always false. This means, we never get the source from the cache and keep setting a new object to the cache, even though the final value is the same.
It still works fine until the report passed to the function (getWorkspaceIcon) has the same policyID (which means the same cache key) but missing policyAvatar.
If the policyAvatar is missing, a default WS avatar will be saved to the cache.
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/libs/ReportUtils.ts#L1939
And because it's a default avatar, we will return it from the cache.
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/libs/ReportUtils.ts#L1930-L1934
What changes do you think we should make in order to solve the problem?

First, we need to solve the issue where we never use the cache if the policy is undefined by using report?.policyAvatar when comparing the cache source. To do that, we can replace avatarURL with policyAvatarURL (we can even use policyExpenseChatAvatarSource so we can remove isDefaultWorkspaceAvatar condition too).
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/libs/ReportUtils.ts#L1927-L1937
Next, to avoid saving default avatar when policyAvatar is missing, we can return the cache if policyAvatar is undefined.
if (iconFromCache && (isSameAvatarURL || isDefaultWorkspaceAvatar || report?.policyAvatar === undefined) && !hasWorkSpaceNameChanged) {
    return iconFromCache.icon;
}

Next, we need to replace getWorkspaceAvatar usage with getWokspaceIcon().source because getWorkspaceAvatar doesn't have the caching and doesn't prioritize report.policyAvatar.
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/pages/home/report/ReportActionItemSingle.tsx#L103
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/pages/ReportAvatar.tsx#L27
Last, I notice that the avatar doesn't update immediately, so we need to update report action item memo to compare for report.policyAvatar too.
https://github.com/Expensify/App/blob/117b96112b4b2de8ead192c9c1da619edb9860fa/src/pages/home/report/ReportActionItem.tsx#L1010-L1014

@mallenexpensify I can reproduce it by sending an invoice from user A to B using a workspace that user B is not a member of.

@Pujan92 plz attempt reproduction, if you're able to, plz review the proposals above. thx

@Nodebrute's alternative solution of using the cached function only for ReportActionItemSingle won't solve the issue in ReportAvatar screen.
I am more inclined towards @bernhardoj's proposal because of the following reasons.

Get rid of the function getWorkspaceAvatar and use the cached function in all the places.
Fix in the caching logic when the policy is unavailable

🎀👀🎀 C+ reviewed

Looks good to me, thanks!

I keep getting this error when sending an invoice.

Are you in the latest main? Also when sending the company website set it to a real valid url

I was facing the same issue with the Control policy, while creating an invoice with Collect policy worked for me.

I'm still facing an error, but a different one. I'm on latest main and sending from a Collect policy.

Just sent one in a collect policy using https://expensify.com
Would you mind trying that?

Still failed.

Nevermind, it works now after I Clear cache and restart

It's very late here, I'll continue tomorrow!

PR is ready
cc: @Pujan92

Automation didn't work, this is in prod as of 3 days ago https://github.com/Expensify/App/pull/49145#issuecomment-2356867180

Contributor: @bernhardoj due $250 via NewDot
Contributor+: @Pujan92 due $250 via NewDot
@Pujan92 plz complete the BZ checklist.
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:

[ ] [@] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [@] Determine if we should create a regression test for this bug.
[ ] [@] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[ ] [@BZ] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

Requested in ND.

$250 approved for @bernhardoj

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:

[X] [@Pujan92] The PR that introduced the bug has been identified. Link to the PR: No, we have had this util function getWorkspaceAvatar  for a long and the invoice feature was added later. So there isn't any specific PR of causing this bug.
[X] [@Pujan92] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: N/A
[X] [@Pujan92] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
[X] [@Pujan92] Determine if we should create a regression test for this bug. - Yes
[X] [@Pujan92] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Regression Test Steps

Upload an avatar for workspace W if it is a default avatar currently
As user A, send an invoice to user B from workspace W(user B isn't a member of this workspace)
As user B, verify the custom avatar has been shown in the report details

I agree we should add the step to check the workspace avatar, that can be added to the testrail that caught this bug: https://expensify.testrail.io/index.php?/tests/view/4864174

Thanks @PauloGasparSv and @rlinoz
Test case created
https://github.com/Expensify/Expensify/issues/431500

$250 approved for @Pujan92

authors: JmillsExpensify MelvinBot Pujan92 bernhardoj garrettmknight izarutskaya mallenexpensify rlinoz


text:
[HOLD for payment 2024-12-03] [hold] Web - Concierge - Take a 2-minute tour task not autocomplete after finishing tour

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Version Number: 9.0.58.0
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
Issue was found when executing this PR: https://github.com/Expensify/App/pull/51153
Issue reported by: Applause Internal Team
Action Performed:

Go to https://staging.new.expensify.com/ and log in with a new account
On the onboarding modal select any option other than 'Something else"
Complete the onboarding flow
Navigate to the Concierge chat
Select the Take a 2-minute tour task
Click on the link and finish the tour

Expected Result:
The task is marked complete automatically upon finishing the tour like other Concierge tasks
Actual Result:
The "Take a 2-minute tour" task is not marked complete automatically
Workaround:
Unknown
Platforms:

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/a25c96b3-1f0b-47c7-9a02-aa39928ecc07

View all open jobs on GitHub
Issue OwnerCurrent Issue Owner: @OfstadC

#51153 is related to this.

I do agree that it's not a blocker and that it should be handled on the backend for the reasons mentioned above by @c3024.
Waiting for your input @mountiny too

@c3024 @rushatgabhane should be assigned and we should mark this optimistically as completed and call the SelfTourViewed command and update the BE to mark the task as complete too

Didn't have time to focus on it internally as I'm focusing on a #stability issue.
@c3024 you can still raise a frontend PR to set this optimistically in the meantime (see @mountiny's comment above).

If you could do it today that'd be great @rushatgabhane

Raised a PR.

@rushatgabhane @c3024 Please complete thee BZ checklist by EOD so we can issue payment tomorrow

@c3024 Offer sent here

Ooop didn't mean to close this. Still need @c3024 to accept Upwork Offer

@c3024 Could you please accept the offer so we can close this GH out? 😃 Thanks so much!

@OfstadC , sorry for the delayed response. This is part of a project and payment is handled here. No payment in this issue. Thanks!

Ah okay! Thanks for letting me know. I will not issue payment here then 😃

authors: IuliiaHerets OfstadC c3024 lakchote mountiny


text:
List of card-level export accounts are not displayed when using Intacct and vendor bills

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Version Number:
Reproducible in staging?:
Reproducible in production?:
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?:
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @joekaufmanexpensify
Slack conversation (hyperlinked to channel name): expense
Action Performed:
Prerequisite: User added a company card

Navigate to company card
Click the added cards to view the details page
Click on export options and select Intacct

Expected Result:
List of card-level export accounts when using Intacct and vendor bills
Actual Result:
List of card-level export accounts are not displayed when using Intacct and vendor bills
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Standalone
[ ] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

View all open jobs on GitHub

Hi, I’m Nicolay from Callstack and I would like to investigate this issue.

@dukenv0307 can you please complete the checklist and then we can close this to handle the payments

authors: m-natarajan mountiny narefyev91


text:
Workspace - Desktop - Blank page is displayed after click on the "Invite" button

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Action Performed:

Launch App and login
Create a workspace
Navigate to the People
Click on the "Invite" button

Expected Result
Invite new members" page should be open.
Actual Result
The blank page is opened.
Workaround:
Unknown
Platform:

Where is this issue occurring?

Desktop App

Version Number: 1.1.7-0
Reproducible in staging?: Yes
Reproducible in production?: No
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: Applause
Slack conversation:
View all open jobs on GitHub

Triggered auto assignment to @johnmlee101 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

authors: MelvinBot isagoico


text:
Feature Request: Add "Are you sure you want to Sign Out?" popup - reported by @dharmik

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Action Performed:

Open app and login
Click on Settings > Sign out

Expected Result:
Popup should appear
Are you sure you want to Sign Out?
Yes Or No
Actual Result:
User signed out. Nothing appear
Workaround:
unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: 1.1.39-0
Reproducible in staging?: Y
Reproducible in production?: Y
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
Issue reported by: @dharmik
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1643910673108429
View all open jobs on GitHub

Triggered auto assignment to @jboniface (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

Triggered auto assignment to @francoisl (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Thanks for the suggestion! As it was discussed in this Slack thread yesterday, we're not going to proceed with this change at the moment.
I left the thread open for a bit to give a chance to everyone to chime in, and it seems like no one else has anything to say anymore, I'm going to close this.

authors: MelvinBot francoisl mvtglobally


text:
$1000 - When you edit a comment, the composer stays hidden on other chats - reported by @thesahindia

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Action Performed:

Open :expensify: on Mobile
Navigate to a chat
Edit a comment
Navigate to a different chat

Expected Result:
Composer should be visible on other chats or user shouldn't be able to navigate to different chat until he cancels/Save the changes
Actual Result:
Composer is hidden for every chat
Workaround:
unknown
Platform:

Where is this issue occurring?

iOS
Android
Mobile Web

Version Number: 1.1.41-0
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43995119/157183657-c4c70cbf-047d-438e-9e82-7f90cc0dc139.mov
Expensify/Expensify Issue URL:
Issue reported by: @thesahindia
Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1645699620022559
View all open jobs on GitHub

Triggered auto assignment to @laurenreidexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

@thesahindia I'm not sure I follow full here - what do you mean by "edit a comment". Do you mean editing a message that has already been sent?

Triggered auto assignment to @robertjchen (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

Composer should be visible on other chats or user shouldn't be able to navigate to different chat until he cancels/Save the changes

Got it! So to clarify my understanding, what should be the proper behavior here?
At the moment, the composer stays open after switching to another chat and switching back. I don't see it as a major issue, but I do see three options to make it "better":

Automatically cancel the edit and hide the composer when switching a chat (Slack does this)
Composer should remain visible on other chats (this might be quite confusing)
Prompt the user to save/cancel the chat (e.g. highlight composer box in red and prevent user from switching, a dialog, etc.)

I see 1 as the path forward here- I'm open to any other thoughts!

I like the 2nd option. 1st option is good but there is a drawback. If the user is in the middle of editing and navigates to some other chat then the changes he made will get discarded.

Got it, that makes sense- it should mirror the behavior on the desktop version (which is working properly, just not on mobile). This is clear to me now, apologies for any initial confusion!
So, the report/proposal here is to address the issue where the composer disappears when switching to other chats on mobile 👍  Thanks again for the report- going to add the External label for the next step of the process.

Triggered auto assignment to @MitchExpensify (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

Upwork Job

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Santhosh-Sellavel (Exported)

Triggered auto assignment to @Beamanator (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Hmm unable to reproduce on mobile web (chrome), latest version - I'll try android

@Beamanator Able to reproduce in mWeb
https://user-images.githubusercontent.com/85645967/158416332-14777a7e-6080-41fb-a308-b6b3c6043e4c.MOV

@Santhosh-Sellavel thanks for the vid, what platform & version are you on?
I just tried on Android, in Chrome browser, v1.1.42-6 and still couldn't reproduce 😅

Waiting on proposals 👍

I guess the interesting thing is:

In web (and Desktop, I assume), when you edit a comment the ReportActionCompose is still showing
In mobile (and mobile web), when you edit a comment the ReportActionCompose disappears even for the chat you're editing

I am guessing this is due to a recent PR, let's see if we can nail that down

In web (and Desktop, I assume), when you edit a comment the ReportActionCompose is still showing
In mobile (and mobile web), when you edit a comment the ReportActionCompose disappears even for the chat you're editing

@Beamanator, I think this is expected, info about it is in https://github.com/Expensify/App/issues/7265

Aha thank you @thesahindia !
@parasharrajat could this issue be a regression of your PR https://github.com/Expensify/App/pull/7390?

Yeah, this is a side-effect from #7390. But I just enabled the flag which was missing from the code. This means this functionality wasn't developed correctly and it had this bug.
Let me check this issue quickly...

Proposal

In ReportScreen's componentWillUnmount call toggleReportActionComposeView(true, true). It will remount the Composer when user closes the report.

The best behavior would be option 1. Where we remount the composer on each report change.

If we do that, what if the user:

Starts editing a comment (so the ReportActionCompose is hidden in that chat)
Navigates to a new chat (now ReportActionCompose should show)
Navigates back to the original chat

In this case wouldn't ReportActionCompose be showing, along with the comment being edited?

Yeah. It will but as soon as the user clicks on the message edit box, the composer hides which is normally happening when you edit a message.

@parasharrajat do you mind testing it and throwing in a short vid to explain what you mean? If I'm understanding correctly the ReportActionCompose will still be showing (in step 3 above) but it will hide if the user clicks in the comment-edit box, which seems like it would result in a weird user experience, maybe I don't understand completely?

Your understanding is correct.

which seems like it would result in a weird user experience

If you feel so then we have to think about an alternative strategy. But I think it is the best fit. On Mobile, we don't focus anything when the report screens loads. There can be multiple draft messages.

Either we remove this feature completely.
Or find something else.

Ok so now I'm thinking this does actually make sense to keep around on mobile because:

When you originally click "Edit comment", you won't be sending a message so it makes sense to hide ReportActionCompose
When you cancel or save your edit, ReportActionCompose comes back (since now you'll be thinking about sending a message)
When you navigate away & come back, you may want to send a message or continue editing, so if you click back in the edit comment box we should hide the ReportActionCompose to make it consistent

I like the idea now, sorry for flip-flopping a bit. @parasharrajat Let's go with your proposal here

📣 @parasharrajat You have been assigned to this job by @Beamanator!
Please apply to this job in Upwork 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 📖

No worries. I appreciate the clarifying questions. It is actually better to discuss it so we are on the same boat.

Invited to job @parasharrajat

@Beamanator question? What should happen when?

user was editing a message and the composer is hidden.
He goes back to LHN.
Then reopen the same report.
Should the composer be shown or not?

So far, I am only forcing the composer on report change.

Asked here https://expensify.slack.com/archives/C01GTK53T8Q/p1647881926785649

@parasharrajat I think we got the answers we need in Slack, do you have any questions before moving forward with a PR?

I will update the PR by monday.

Thanks ... I like that idea too, I agree it’s not necessary to keep the edit box open when navigating to LHN and back :thumbsup:

@Beamanator Do I need to add this as well?

@parasharrajat Yes we should include the decision made in Slack. Would you mind restating exactly what you plan to do before moving forward with this?

Ok, I found that if we want to close the edit box while going back to LHN, we have to lose the draft messages as well.
Edit box depends on the presence of draft message directly https://github.com/Expensify/App/blob/1ff6625a19f56f9d636edc09a1d2f76d5f7a893c/src/pages/home/report/ReportActionItem.js#L139

Ok, personally I think that's ok because it's just a draft edit

Ok, I will update the PR.

@Beamanator  Ok, So there are two ways, I can think of.

I use withReportActionsDrafts HOC on ReportScreen to get all the reportActionsID with keys. Then use WithDrawerState to set those drafts off when the drawer is opened.
Secondly, I can directly use WithDrawerState on the ReportActionItem and reject the draft when the drawer is Opened.

Ok so just to make sure I'm following correctly:

this.props.draftMessage (in ReportActionItem.js) is where we're storing the draft of an edited message (not the draft of a new message)
You're thinking we can just kill a report's draft (probably using Report.saveReportActionDraft, storing null) when the LHN opens up

If this is correct, I'm thinking the second option may be more efficient since we only have to deal with 1 report's draft at a time, what do you think?

Yup, you are correct. But a report can have multiple drafts for actions.

Ok and that's why in your sample code you're looping through all drafts of a specific reportID, which I bet you'd have to do in either case, thanks for reminding me about that 👍
A few more questions related to this change we're thinking about making:

Now that we're planning to get rid of message-edits once a user navigates back to the LHN, do you think it even makes sense to store these in Onyx anymore? A.k.a. if we don't care about message-edit drafts when we switch to a new report, wouldn't we also not care about saving the drafts if the user closes the app, for example?
On large screen devices we won't "open the LHN" ever so to make behavior consistent would we want to kill message-edit drafts if the user changes reports? Or do we want to :donothing: for big screen devices? I'm leaning toward :donothing:

Yeah, good points.
I have a second thought about this change. We are basically removing the drafts feature from the app. Do you think we should take the opinion of a few more people? Let me know if this is the final decision, I will look into your questions as well.

Yeah I was thinking something similar 👍 I agree we should get more opinions, if you could continue the same chain as before but re-send to the channel & maybe tag contributor-management-engineering as well that would be very helpful

New Upwork Job (previous one closed)
Price doubled!

Ping'd CMEs in internal channel to try to get more eyes 👁

We are basically removing the drafts feature from the app.

I don't think we should do this. If I start editing a message on a chat, and then I need to go reference something from another chat, I want to be able to come back to my draft and continue editing. If I have been editing a message and I go to another chat I should also be able to send messages there. That should be possible right? Is there another case I'm not thinking of?

If I have been editing a message and I go to another chat I should also be able to send messages there. That should be possible right?

Yeah, that is possible.

What should happen when?

user was editing a message and the composer is hidden.
He goes back to LHN.
Then reopen the same report.
Should the composer be shown or not?

If you do this on web / desktop then the composer will be shown, so I think it should match on mobile. In my opinion, we should let the user have the option to continue editing or to send another message. Again that behavior would match desktop. To make that happen I think we should allow the user to unfocus the composer (and dismiss the keyboard) if they click outside of it on mobile. Maybe that's a separate issue.

Left a big comment w/ multiple ideas & ping'd a few more people in Slack: https://expensify.slack.com/archives/C01GTK53T8Q/p1651495589126309?thread_ts=1647881926.785649&cid=C01GTK53T8Q

So sorry, I'm new to Expensify and I don't understand what the issue is here. Where in the attached video is something incorrect?

Doubled!

Ping'd the slack channel again to see if anyone can help come to a final decision :D

Bump! Any update?

I'm getting fewer and fewer responses to my posts in slack 😅 I don't feel comfortable moving forward till we have more feedback on the thought so I will tag CMEs and try to get more thoughts
@MitchExpensify I think you can hold off doubling this time please :D Since we don't have a solid way forward yet

Heads up I'm working on this internally in a duplicate issue here and found a pretty simple solution.

I think the correct behavior is that we should hide and show the "composer" only when the edit comment field is focused or blurred.

Has anyone been hired? If not, I think we can just close this one (and the Upwork job) and have @parasharrajat and @Beamanator test my PR linked to the duplicate issue.

@marcaaron I ended up hiring @parasharrajat here: https://github.com/Expensify/App/issues/8031#issuecomment-1073543793
After that, we've been discussing what to do in some other situations (see Slack thread: https://expensify.slack.com/archives/C01GTK53T8Q/p1652268683129369?thread_ts=1647881926.785649&cid=C01GTK53T8Q)
And this has been delayed due to lack of responses, which is why I just brought this to an internal slack channel as well

If you already have a PR up, maybe we can pay @parasharrajat to help test & review it? (I'll help as well)

What is decided here? Should I close my PR?

Yes, want to help us review this solution instead --> https://github.com/Expensify/App/pull/9060

Added you guys there.

Not overdue, PR testing and reviewing in progress

I believe this can be closed b/c the fix was implemented in this PR: https://github.com/Expensify/App/pull/9060

Agree!

Note: I was hired for this issue here and It was decided that this issue will be solve internally and I will review it as C+. Also, I closed my PR for the same.

Yeah, you are correct. Thanks.

@MitchExpensify, the reporting compensation is also pending.

Thanks for the heads up team! I have made a note to issue payment tomorrow as that will be 7 days since the fix was deployed here

Payments made and contract ended - Thanks @parasharrajat & @thesahindia!

authors: Beamanator MelvinBot MitchExpensify Santhosh-Sellavel frenkield laurenreidexpensify marcaaron mvtglobally neil-marcellini parasharrajat robertjchen thesahindia


text:
Show comment/requests in report preview

Details
cc @JmillsExpensify, @trjExpensify
Fixed Issues

$ https://github.com/Expensify/App/issues/21178
Tests

Log into your account in newdot

Request money from someone else and add a comment while doing so

Confirm the comment immediately shows in the request:

Request money again from the same person.

Confirm that, instead of the comment, the number of requests show immediately:

[x] Verify that no errors appear in the JS console

Offline tests
Same as tests but offline
QA Steps
Same as tests

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Yes, this should be ready for review

@abdulrahuman5196 bump!

Sorry for the delay. Will review in couple of hours.

@Gonals
Request count is not updated in the preview if a request is deleted, the preview is only updated when the request is added. I assume it has to do with backend(not sure though). should that be a separate PR?
https://github.com/Expensify/App/assets/46707890/02e79bff-b3c9-41f2-98a4-35181bf43315

@Gonals Request count is not updated in the preview if a request is deleted, the preview is only updated when the request is added. I assume it has to do with backend(not sure though).
Screen.Recording.2023-08-02.at.9.35.02.PM.mov

Nice catch! it is 50-50.
@abdulrahuman5196 I have fixed the frontend here to optimistically update it, but the backend bug remains. Let's ignore it for this PR and I'll fix it in a different issue. Let's see if we can merge today, as I'm OOO staring tomorrow!

@Gonals Got it. I tested now. I think the optimistically updating data is also not complete and in cases I still seeing issues.
Like

Description is not updating in preview if we delete all requests and keep only one request with description

But I am fine with this, given we are planning to create separate bug to address the request count not getting updating on requests deletion/updation. I think it would be best to re-test the optimistic function and backend verification as well in that issue.

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/46707890/0b9b84e7-750d-45b3-ab3e-83f63a04005c

Mobile Web - Chrome

https://github.com/Expensify/App/assets/46707890/49d1eece-7f9f-45d6-95b6-85bf40f5aa34

Mobile Web - Safari

https://github.com/Expensify/App/assets/46707890/07f610be-0f53-4ffa-a4ef-d662161e50f2

Desktop

https://github.com/Expensify/App/assets/46707890/0ad3ee17-043f-4e6f-82cc-8491f481940a

iOS

https://github.com/Expensify/App/assets/46707890/10b951f0-b7a7-44c1-ac32-4309a23a27bf

Android

https://github.com/Expensify/App/assets/46707890/afd4c5f5-6a61-439d-adb0-f6a858aa3f4e

@Gonals Changes looks good. We have to create 2 issues

Request count/description is not properly updated on request deletion/updation

Request count/description is not updated on workspace chat money requests during addition for any pre-existing workspace. But working fine for new workspaces.

https://github.com/Expensify/App/assets/46707890/4a16b7a9-fa0b-4823-861e-27bd1f3928eb

Do we need to update this function usage to pass comment param https://github.com/Expensify/App/blame/2335cbaf854f236db28cbbc72fa0446a6584d78c/src/libs/actions/IOU.js#L1257

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.52-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/luacmartins in version: 1.3.52-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.52-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

source: gharchive/pull-request

authors: Gonals MonilBhavsar OSBotify abdulrahuman5196


text:
Default to true to make type happy

Details
Fix type error on main
Fixed Issues
$ None, just slack: https://expensify.slack.com/archives/C01GTK53T8Q/p1698864273831739
Tests
None needed, we default to true already in getDisplayNameForParticipant which is where we pass the param shouldFallbackToHidden

[ ] Verify that no errors appear in the JS console

Offline tests
None needed
QA Steps
None needed

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/cristipaval in version: 1.3.95-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.95-9 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/cristipaval in version: 1.3.96-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.3.96-15 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

authors: Beamanator OSBotify cristipaval


text:
Add the policy tax trackingEnabled

Details

This PR adds the policy.tax.trackingEnabled property so we copy what is in the db policy object
Fixed Issues

$ https://github.com/Expensify/App/issues/36176
Tests

Make sure Tax is enabled in Old Dot.
Add some tax policies in Old Dot.
Add a member to your workspace.
select a user from your workspace with enabled policies.
Click on request money as either manual or scan.
enter amount.
click on Show More and select tax rate.
Verify it worked fine

[ ] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

Same as tests

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos
simple change, works fine

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@ishpaul777 ok please go ahead, I think you will need to have the Collect policy set up

yep that should be it, you need to invite in another user to the policy btw to get the workspace chat

@ishpaul777 thanks! updated!

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/thienlnam in version: 1.4.42-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/chiragsalian in version: 1.4.42-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

authors: OSBotify mountiny


text:
Hide the double offline indicator in bank steps

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/36458
$ https://github.com/Expensify/App/issues/36458#issuecomment-1943002051
Tests

[X] Verify that no errors appear in the JS console

Pre-requisite: the user must be logged in and have created a workspace.

Go to Workspace > Bank account.
Initiate the add BA flow until you reach the Personal info double check page.
Disable the internet connection.
Validate that only one offline indicator is shown

Offline tests

Pre-requisite: the user must be logged in and have created a workspace.

Go to Workspace > Bank account.
Initiate the add BA flow until you reach the Personal info double check page.
Disable the internet connection.
Validate that only one offline indicator is shown

QA Steps

[x] Verify that no errors appear in the JS console

Pre-requisite: the user must be logged in and have created a workspace.

Go to Workspace > Bank account.
Initiate the add BA flow until you reach the Personal info double check page.
Disable the internet connection.
Validate that only one offline indicator is shown

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes

[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)

[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/mountiny in version: 1.4.43-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

authors: OSBotify abzokhattab akinwale