[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

[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