[$500] Status with custom time doesn't work

[m-natarajan]

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.16-3
Reproducible in staging?: y
Reproducible in production?: y
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: @dylanexpensify
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1703354936560399?thread_ts=1703016500.538419&cid=C049HHMV9SM

Action Performed:

1. Access Profile > Status
2. Add any custom status
3. Click on Clear After > Custom > Date
4. Click Save

Expected Result:

It should keep the date you select and save.

Actual Result:

Didn't keep my selected date, and I was unable to save the status

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

Add any screenshot/video evidence

Recording.354.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~019c1da8c2e9f0e2ec
• Upwork Job ID: 1738972785687736320
• Last Price Increase: 2024-01-07

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~019c1da8c2e9f0e2ec

[melvin-bot]

Triggered auto assignment to @anmurali (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (External)

[ishpaul777]

should be resolved after #33525 is merged and deployed

[rayane-d]

since this bug is handled here: #33525
I am proposing a feature to prevent this bug in the future:

Proposal

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

The current issue is that within our codebase, instances of components like DatePicker are not consistently wrapped in InputWrapper when used within FormProvider. This inconsistency can lead to problems with state management and form validation, as InputWrapper is essential for correctly updating the form's state based on user input.

What is the root cause of that problem?

The primary cause of this issue is the lack of a defined coding standard or automated enforcement / warning mechanism ensuring that components are always wrapped in InputWrapper when used within FormProvider. This leads to situations where developers might inadvertently omit the InputWrapper, resulting in components that do not function as expected within the form context.

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

To address this inconsistency and enforce a standard coding practice, I propose creating a custom ESLint rule specifically tailored for our project. This rule will automatically enforce the use of InputWrapper around components when they are children of FormProvider.

What alternative solutions did you explore? (Optional)

N/A

[Famzy-codes]

Proposal

Problem Statement:
When attempting to set a custom date under "Clear After" within "Access Profile > Status" and saving, the selected date is not retained, leading to an inability to save the status with the expected date.

Root Cause Analysis:
Upon analysis, the issue appears to stem from the failure to persist the selected date in the "Clear After" field when saving the status. This indicates a breakdown in the data persistence mechanism associated with custom dates in this particular section of the application.

Proposed Solution:
To rectify this issue, I propose inspecting the data storage and retrieval mechanism linked with the "Clear After" functionality under the "Access Profile > Status." This would involve:

1. Reviewing the code logic governing the handling of custom dates during the save operation.
2. Identifying any errors or omissions in the data persistence flow related to storing and retrieving selected dates.
3. Implementing necessary adjustments to ensure the proper storage and retrieval of custom dates when saving the status.

Alternative Solutions Explored:
Exploring alternative data storage approaches or utilizing client-side storage mechanisms was considered. However, the primary solution centers around rectifying the data persistence issue within the existing storage infrastructure to ensure the accurate saving of selected dates.

I'm prepared to delve into the codebase and address this data persistence issue promptly to ensure the accurate retention and saving of custom dates within the "Clear After" functionality of "Access Profile > Status."

Please note that any proposed changes will be thoroughly tested across supported platforms (MacOS: Chrome / Safari) to guarantee the resolution's effectiveness.