[HOLD for payment 2024-12-11] [HOLD App#53229] Accounting - Next button doesn't have bottom margin on intacct setup first page

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.67-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Create a workspace and enable accounting
2. Navigate to accounting and Tap on connect on Sage Intacct
3. Observe the Next button and tap on next

Expected Result:

There is a bottom margin for next button

Actual Result:

There is no bottom margin for next button on the first setup page of Intacct

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
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

stg.2711.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (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.

[Krishna2323]

Edited by proposal-police: This proposal was edited at 2024-11-27 16:46:11 UTC.

Proposal


Please re-state the problem that we are trying to solve in this issue.

Accounting - Next button doesn't have bottom margin on intacct setup first page

What is the root cause of that problem?

• Safe area padding bottom is not applied.
  

  App/src/pages/workspace/accounting/intacct/SageIntacctPrerequisitesPage.tsx

  Lines 88 to 96 in 9ea0f51

  	<FixedFooter style={[styles.mtAuto]}>
  	<Button
  	success
  	text={translate('common.next')}
  	onPress={() => Navigation.navigate(ROUTES.POLICY_ACCOUNTING_SAGE_INTACCT_ENTER_CREDENTIALS.getRoute(policyID))}
  	pressOnEnter
  	large
  	/>
  	</FixedFooter>

What changes do you think we should make in order to solve the problem?


• We should use const safePaddingBottomStyle = useSafePaddingBottomStyle(); and pass includeSafeAreaPaddingBottom={false} to ScreenWrapper.
• Or we can use useSafePaddingBottomStyle inside FixedFooter and remove useSafeAreaInsets.

What alternative solutions did you explore? (Optional)

Result

[melvin-bot]

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

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[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.

[lanitochka17]

Production:

prod.2711.mp4

[mountiny]

cc @chrispader @kirillzyusko Another bottom margin one

[aldo-expensify]

@mountiny 👋 , are you going to handle this? (asking because of the self-assign :) )

[mountiny]

Based on the video this is very minor and we wont block deploy on this one.

@kirillzyusko lets still assign you to fix these

[melvin-bot]

Current assignee @JmillsExpensify is eligible for the Bug assigner, not assigning anyone new.

[mountiny]

Putting this on hold for holistic safearea management

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[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 9.0.70-9 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• feat: new way to handle insets in the app #53250

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

[melvin-bot]

@mountiny @JmillsExpensify @mountiny The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[melvin-bot]

@JmillsExpensify, @mountiny Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[mountiny]

Payments been handled on other issue as there was bunch of issues linked to one PR edge-to-edge, no regression test required as we will notice