[$500] Domain Card - User can edit the date in expenses related to the assigned domain card

[lanitochka17]

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.42-1 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): tester+domaincard@applausecard.expensifail.com Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: Applause - Internal Team Slack conversation:

Action Performed:

1. Open App or go to staging.new.expensify.com
2. Log in with tester+domaincard@applausecard.expensifail.com
3. Navigate to the workspace chat for "Domain Card tests - DO NOT DELETE"
4. Verify there's a report that contains the expenses related to the assigned domain card
5. Click on the report
6. Verify you can see the individual expenses
7. Click on a individual expense
8. Verify the fields "Amount" and "Date" are not editable

Expected Result:

Fields "Amount" and "Date" are not editable

Actual Result:

User has access to edit the date. (User receives an error after editing the date, but can try to do it)

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

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/b0d0005b-885b-42da-9570-5bdc070f27b0

https://github.com/Expensify/App/assets/78819774/a19bd932-cb63-4b24-a708-2d9bde3896de

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~010604e6d9dd675bc1
• Upwork Job ID: 1758194441775136768
• Last Price Increase: 2024-03-14
• Automatic offers:
• FitseTLT | Contributor | 0

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~010604e6d9dd675bc1

[melvin-bot[bot]]

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

[melvin-bot[bot]]

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

[lanitochka17]

We think that this bug might be related to #vip-vsp CC @quinthar

[FitseTLT]

Proposal

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

Domain Card - User can edit the date in expenses related to the assigned domain card

What is the root cause of that problem?

The canEditFieldOfMoneyRequest logic doesn't align with the BE requirements to allow editing date field and it allows the edit of date field for domain card transaction unlike amount which is disabled as in here https://github.com/Expensify/App/blob/1c0d126ffb34e1fd103c9f6067b76af688638d47/src/libs/ReportUtils.ts#L2162-L2164

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

We should add a code before here https://github.com/Expensify/App/blob/1c0d126ffb34e1fd103c9f6067b76af688638d47/src/libs/ReportUtils.ts#L2162

if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.DATE) {
        if (TransactionUtils.isCardTransaction(transaction)) {
            return false;
        }
    }

or change https://github.com/Expensify/App/blob/1c0d126ffb34e1fd103c9f6067b76af688638d47/src/libs/ReportUtils.ts#L2162 to

    if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.AMOUNT || fieldToEdit === CONST.EDIT_REQUEST_FIELD.CURRENCY || fieldToEdit === CONST.EDIT_REQUEST_FIELD.DATE) {

What alternative solutions did you explore? (Optional)

[allroundexperts]

@miljakljajic Who can edit these fields? Is it that no one should edit these?

[wildan-m]

Could someone add me to the "Domain Card tests - DO NOT DELETE" group? Alternatively, how can we create the domain card? Can we use a fake card for this purpose?

wildevemail+1@gmail.com

[melvin-bot[bot]]

@miljakljajic, @allroundexperts Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[brandonhenry]

Is this accepting proposals?

[allroundexperts]

@brandonhenry Yes. @miljakljajic Bump on the above question 😄

[melvin-bot[bot]]

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

[miljakljajic]

For non-reimbursable expenses no one should be able to edit the date or amount.

[melvin-bot[bot]]

@miljakljajic @allroundexperts this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[brandonhenry]

Proposal

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

The issue is that users are currently able to edit the date field in expenses related to the assigned domain card without receiving any error message in the UI, even though such edits should not be allowed. The desired behavior is for the UI to present an error message when a user attempts to edit the date, effectively preventing the edit from being submitted to the backend.

What is the root cause of that problem?

The root cause of this problem lies in the frontend logic, specifically within the EditRequestPage or related components handling the editing process. There is a missing validation step that should check if the transaction being edited is associated with a domain card and, if so, should prevent the edit and display an appropriate error message to the user.

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

To resolve this issue, we need to implement a validation mechanism within the frontend that:

1. Detects when a user attempts to edit the date field of a transaction related to a domain card.
2. Prevents the edit from being applied.
3. Displays an error message to the user explaining that editing the date for domain card transactions is not permitted.

This could be achieved by enhancing the existing edit handling logic in the EditRequestPage component or wherever the edit logic is currently implemented. Specifically, we can add a condition to the event handler responsible for saving edits that checks if the transaction is related to a domain card and if the field being edited is the date. If both conditions are met, the function should prevent the edit and trigger an error message instead of proceeding with the save operation.

Here is a conceptual code snippet to illustrate the proposed enhancement:

// Assuming this function is called when the user attempts to save their edits
function onSaveEdit(field, newValue) {
    // Check if the field being edited is the date and if the transaction is for a domain card
    if (field === 'Date' && isDomainCardTransaction(transaction)) {
        // Prevent the save and display an error message
        showError('Editing the date for domain card transactions is not allowed.');
        return;
    }

    // Proceed with saving the edit if the above conditions are not met
    saveEdit(field, newValue);
}

// Utility function to determine if a transaction is related to a domain card
function isDomainCardTransaction(transaction) {
    // Implementation depends on how domain card transactions are identified
    // This could involve checking the transaction's properties, associated policy, etc.
}

// Function to display error messages to the user
function showError(message) {
    // Implementation depends on how errors are displayed in the UI
    // This could involve setting state to trigger a modal, toast, or inline error message
}

If this makes sense, I can provide specific areas

[wildan-m]

Proposal

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

Some card fields in expenses related to the card are editable (Date) and interactive (Card).

I think in addition to being non-editable, it should also be non-interactive. What does that mean? If hovered/clicked, they shouldn't display a hand cursor or change to a hover style.

Current state:

https://github.com/Expensify/App/assets/11847279/5136ebf1-4046-4aab-9ef0-4a84f77ee03c

Suggested revision:

https://github.com/Expensify/App/assets/11847279/73b29870-fda0-4ba8-8b9d-99eb4c7f7940

What is the root cause of that problem?

We are not included CONST.EDIT_REQUEST_FIELD.DATE to this check https://github.com/Expensify/App/blob/5d2933df279e1cda145ee3abef764b9862b5f7e4/src/libs/ReportUtils.ts#L2180-L2184

And not disable interactive in card menu item: https://github.com/Expensify/App/blob/5d2933df279e1cda145ee3abef764b9862b5f7e4/src/components/ReportActionItem/MoneyRequestView.tsx#L405-L413

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

Change this line to.

    if (fieldToEdit === CONST.EDIT_REQUEST_FIELD.AMOUNT || fieldToEdit === CONST.EDIT_REQUEST_FIELD.CURRENCY || fieldToEdit === CONST.EDIT_REQUEST_FIELD.DATE) {
        if (TransactionUtils.isCardTransaction(transaction)) {
            return false;
        }

And add interactive={false} to this card menu item.

                {isCardTransaction && (
                    <OfflineWithFeedback pendingAction={getPendingFieldAction('cardID')}>
                        <MenuItemWithTopDescription
                            description={translate('iou.card')}
                            title={cardProgramName}
                            titleStyle={styles.flex1}
                            interactive={false}
                        />
                    </OfflineWithFeedback>
                )}

What alternative solutions did you explore? (Optional)

[melvin-bot[bot]]

@miljakljajic, @allroundexperts Eep! 4 days overdue now. Issues have feelings too...

[melvin-bot[bot]]

@miljakljajic, @allroundexperts Still overdue 6 days?! Let's take care of this!

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

@miljakljajic @allroundexperts this issue is now 3 weeks old. There is one more week left before this issue breaks WAQ and will need to go internal. What needs to happen to get a PR in review this week? Please create a thread in #expensify-open-source to discuss. Thanks!

[melvin-bot[bot]]

@miljakljajic, @allroundexperts 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!

[melvin-bot[bot]]

@miljakljajic, @allroundexperts 12 days overdue. Walking. Toward. The. Light...

[melvin-bot[bot]]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot[bot]]

@miljakljajic @allroundexperts this issue is now 4 weeks old and preventing us from maintaining WAQ, can you:

• Decide whether any proposals currently meet our guidelines and can be approved as-is today
• If no proposals meet that standard, please take this issue internal and treat it as one of your highest priorities
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[melvin-bot[bot]]

Current assignee @allroundexperts is eligible for the Internal assigner, not assigning anyone new.

[allroundexperts]

Missed this completely. Reviewing now.

[melvin-bot[bot]]

This issue has not been updated in over 14 days. @miljakljajic, @allroundexperts eroding to Weekly issue.

[allroundexperts]

Thanks for the proposals @brandonhenry and @wildan-m. @brandonhenry We don't usually add the validation when making the API call. We should disable the menu item like we are doing for other fields.

@wildan-m I see that you've proposed a small change to the proposal @FitseTLT made earlier. However, I think it is really minor and would have been caught during the PR review.

@FitseTLT proposal looks good to me. They were the first to propose the correct RCA and the fix.

🎀 👀 🎀 C+ reviewed

[melvin-bot[bot]]

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

[robertjchen]

Thanks for the discussion here, let's move forward with @FitseTLT 's proposal 👍

[melvin-bot[bot]]

Current assignee @allroundexperts is eligible for the External assigner, not assigning anyone new.

[melvin-bot[bot]]

📣 @FitseTLT 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link Upwork job Please accept the offer 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 📖

[miljakljajic]

Adding to Wave Collect > Release 1

[miljakljajic]

The automated offer link doesn't seem to work, keeping this here for a record when payment is due: https://www.upwork.com/nx/wm/workroom/36700816/overview

[FitseTLT]

PR will be in 2 days

[robertjchen]

@FitseTLT thanks, let us know when it's ready! 🙇

[FitseTLT]

PR ready

[trjExpensify]

@miljakljajic as a bug that doesn't block the release, I'm moving this into Polish on the project board.

[miljakljajic]

Thank you @trjExpensify

[FitseTLT]

Can we please get a new C+ here? I think @allroundexperts is busy and the pr is stuck for weeks.

[allroundexperts]

@FitseTLT The checklist is already complete. Apologies for the delay here. If I'm unable to complete the review by tomorrow, we can re-assign.

[allroundexperts]

@FitseTLT I reviewed this yesterday and left some comments.

[melvin-bot[bot]]

This issue has not been updated in over 15 days. @robertjchen, @miljakljajic, @allroundexperts, @FitseTLT eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[robertjchen]

Looks like the associated change was deployed- closing this out unless there are any other remaining items?

[FitseTLT]

@robertjchen Payment hasn't been issued yet, so please re-open it. @miljakljajic Payment is overdue, can u please process the payment, the linked pr has been deployed to production three weeks ago. Thx

[melvin-bot[bot]]

@robertjchen, @miljakljajic, @allroundexperts, @FitseTLT Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot[bot]]

@robertjchen, @miljakljajic, @allroundexperts, @FitseTLT 6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[miljakljajic]

paid

[allroundexperts]

@miljakljajic Can we please have a payment summary here? Thanks!