[$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 [email protected] 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): [email protected]
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 [email protected]
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?

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6380969_1708019494480.Safari-Domain-Card-Date-Edit.1.mp4

Bug6380969_1708019494545.Desktop-Domain-Card-Date-Edit.mp4

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]

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

[melvin-bot]

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

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

App/src/libs/ReportUtils.ts

Lines 2162 to 2164 in 1c0d126

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

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

We should add a code before here

App/src/libs/ReportUtils.ts

Line 2162 in 1c0d126

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

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

or change

App/src/libs/ReportUtils.ts

Line 2162 in 1c0d126

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

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?

[email protected]

[melvin-bot]

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

[melvin-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]

@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]

@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]

📣 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:

GMT20240301-152519_Clip_Wildan.M.s.Clip.03_01_2024.mp4

Suggested revision:

GMT20240301-152714_Clip_Wildan.M.s.Clip.03_01_2024.mp4

What is the root cause of that problem?

We are not included CONST.EDIT_REQUEST_FIELD.DATE to this check

App/src/libs/ReportUtils.ts

Lines 2180 to 2184 in 5d2933d

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

And not disable interactive in card menu item:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 405 to 413 in 5d2933d

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

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]

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

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

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]

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

[melvin-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!

[JmillsExpensify]

Reopening for payment summary.

[miljakljajic]

@allroundexperts is owed 500 USD for work reviewing this PR.

[JmillsExpensify]

$500 approved for @allroundexperts