[HOLD for payment 2024-06-11] [Held PR #42248] [Search v1] Date and Merchant value text isn't line with each other in the row

[izarutskaya]

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.74.1
Reproducible in staging?: Y
Reproducible in production?: Unable to check
Found when validating PR : #41672
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team

Action Performed:

Precondition: Have at least one submitted expense.

1. Log in with an expensifail account
2. Navigate to Account settings - Troubleshoot - New Search Page

Expected Result:

The whole row should be in line.

Actual Result:

Date and Mearchant value text isn't line with each other in the row.

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @zanyrenney

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

Triggered auto assignment to @zanyrenney (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open Staging deploy checklist to see the list of PRs included in this release, then work quickly on the following:

1. If you find which PR caused the issue/bug, you can reassign it to the person responsible for it.
   • If the author is OOO or won’t get online before the daily deploy is due, you are responsible for finding the best fix/path forward. Don’t hesitate to ask for help!
2. Try to reproduce the issue, if the bug is on production, remove the DeployBlocker label but stay assigned to fix it (or find out which PR broke it to get help from the author).
   • You can adjust the urgency of the issue to better represent the gravity of the bug.
   • If the issue is super low priority, feel free to un-assign yourself.
   • Be careful with PHP warnings, sometimes it is more complex than just adding a null coalescing operator as they might be uncovering some bigger bug.
   • If it was a one-off issue that requires no action (for example, Bedrock was down or it is a duplicated issue), you can close it.

Remember rule #2: Never un-assign yourself from a real DeployBlocker unless you are 100% sure someone else is assigned and will take care of it.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[izarutskaya]

@zanyrenney 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.

[Beamanator]

@Expensify/design this looks like a bug, yeah? I think we can call this NAB cuz it's not very noticeable, thoughts?

[trjExpensify]

You can only access the search page right now via the troubleshooting menu (or knowing the URL directly) until we add the bottom tab for Search to release it. So definitely not a deploy blocker. 👍 CC: @luacmartins

[shawnborton]

Two things for you to follow up on @luacmartins:

The line height of any font/text that is at a size of 13px should be using 16px. Right now it's 18px for some reason?

Then if we take the min-height off of the value, it should vertically center itself just fine.

So what we might want to consider is putting the min-height of 20px on the flex wrapper that wraps the value, and then make sure everything is vertically centered from there. Let me know if that makes sense!

[Kicu]

Hey I will take care of this because I'm actively working on Search components and its cheaper to just add this small fix as part of another PR, than to create a whole new PR just for this.

thanks @shawnborton for pointing out the font sizes, I'll straighten this out.

[shawnborton]

Wonderful - thanks!

[Kicu]

@shawnborton inside this PR I have updated text aligning: #42248

You can check the screen or video, or run my branch if thats something you can do.

Not every font is the same size - for example names are smaller (I believe this is on purpose) but I expect things to look aligned/centered. Please tell me if this looks ok to you.

[shawnborton]

Sounds good, can you actually leave a similar comment on that PR too so we know to look for it during review? I'll spin up a test build on that PR as well. Thanks!

[trjExpensify]

Just to confirm, the PR for Add sorting will take care of this issue, right?

[shawnborton]

Yup!

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.78-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [Search v1] Add sorting  #42248

If no regressions arise, payment will be issued on 2024-06-11. 🎊

For reference, here are some details about the assignees on this issue:

• @Kicu does not require payment (Contractor)

[melvin-bot]

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:

• [@luacmartins] The PR that introduced the bug has been identified. Link to the PR:
• [@luacmartins] 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:
• [@luacmartins] 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:
• [@Kicu] Determine if we should create a regression test for this bug.
• [@Kicu] 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.
• [@zanyrenney] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[zanyrenney]

no payment due:

@Kicu does not require payment (Contractor)