[HOLD for payment 2024-10-30] [$250] Assign task - Inconsistent Button Behavior Between Submit and Assign Task After Navigating via URL

[IuliiaHerets]

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: v9.0.47-1
Reproducible in staging?: Y
Reproducible in production?: Y
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

1. Go to Settings > Create Workspace.
2. In Workspace Chat, click the plus sign.
3. Select "Submit Expense," add a merchant, and copy the URL.
4. Open the copied URL in a new tab, return to the previous tab, and submit the expense.
5. Go back to the new tab and notice the Submit button is disabled.
6. In Workspace Chat, click the plus sign again and select "Assign Tasks."
7. Add a title, copy the URL, and open it in a new tab.
8. Return to the previous tab, click Confirm Task, and return to the new tab.
9. Notice that the Confirm button is not disabled, but clicking it shows an incorrect error saying "Add title and share" even though both fields are filled.

Expected Result:

After navigating between pages using URLs, both the Submit and Confirm buttons should behave consistently—either both should be disabled after actions or display correct error messages.

Actual Result:

The Submit button is disabled as expected, but the Confirm button displays an incorrect error message, causing inconsistency.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6630676_1728562512925.Screen_Recording_2024-10-10_at_5.11.48_AM.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021844734228925480640
• Upwork Job ID: 1844734228925480640
• Last Price Increase: 2024-10-11

Issue Owner

Current Issue Owner: @zanyrenney

[melvin-bot]

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

[IuliiaHerets]

@zanyrenney FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[NJ-2020]

Edited by proposal-police: This proposal was edited at 2024-10-10 14:47:50 UTC.

Proposal

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

Assign task - Inconsistent Button Behavior Between Submit and Assign Task After Navigating via URL

What is the root cause of that problem?

After the first tab confirm the task the ONYXKEYS.TASK value become undefined and then when we click the confirm button on the second tab we got an error message saying: Please enter a title and select a share destination.

That is because when we click the confirm button it invoke this function and checking if the task?.title is not empty, since the task value is undefined so it return above error message

App/src/pages/tasks/NewTaskPage.tsx

Lines 117 to 121 in da700c5

	const onSubmit = () => {
	if (!task?.title && !task?.shareDestination) {
	setErrorMessage(translate('newTaskPage.confirmError'));
	return;
	}

And why we still kept seeing the title value in the title input, because when we open the page we set the useState title value to task.title inside this useEffect

App/src/pages/tasks/NewTaskPage.tsx

Lines 104 to 107 in da700c5

	// If we have a title, we want to set the title
	if (task?.title !== undefined) {
	setTitle(task.title);
	}

But when the task value becomes undefined the useEffect hook will be triggered since the task?.title value changed, but it do not remove the value from the title input because it will update the useState if the task?.title is not undefined

App/src/pages/tasks/NewTaskPage.tsx

Lines 104 to 107 in da700c5

	// If we have a title, we want to set the title
	if (task?.title !== undefined) {
	setTitle(task.title);
	}

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

We can remove the if condition inside the useEffect

...
setTitle(task?.title ?? '');

We can do the same for description and assignee

Result

Screen.Recording.2024-10-10.at.07.45.43.mov

What alternative solutions did you explore? (Optional)

[bernhardoj]

Proposal

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

Inconsistent submit button behavior between the task page and money request page.

What is the root cause of that problem?

From the OP video, there are actually a few problems. When we submit a money request or a task, we clear out the info from the Onyx. For the money request page, a blank screen is shown. It happens after #42413 where we show an empty view using renderListEmptyContent.

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 719 to 721 in da700c5

	{flattenedSections.allOptions.length === 0 ? (
	renderListEmptyContent()
	) : (

Previously, we show a loader only if showLoadingPlaceholder is true.

Now, the condition is inside the function which will render null if both conditions are false.

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 484 to 492 in 36c45f4

	const renderListEmptyContent = () => {
	if (showLoadingPlaceholder) {
	return <OptionsListSkeletonView shouldStyleAsTable={shouldUseUserSkeletonView} />;
	}
	if (shouldShowListEmptyContent) {
	return listEmptyContent;
	}
	return null;
	};

The submit button is also disabled because the selected participants are now 0.

App/src/components/MoneyRequestConfirmationList.tsx

Line 841 in da700c5

const shouldDisableButton = selectedParticipants.length === 0;

The task page, on the other hand, uses a local state to show the task information and only updates if the onyx value is not undefined. So, when the onyx value is cleared, the local state still contains the previous value.

App/src/pages/tasks/NewTaskPage.tsx

Lines 84 to 112 in da700c5

	if (task?.assignee) {
	const displayDetails = TaskActions.getAssignee(task?.assigneeAccountID ?? -1, personalDetails);
	setAssignee(displayDetails);
	}
	// We only set the parentReportID if we are creating a task from a report
	// this allows us to go ahead and set that report as the share destination
	// and disable the share destination selector
	if (task?.parentReportID) {
	TaskActions.setShareDestinationValue(task.parentReportID);
	}
	// If we have a share destination, we want to set the parent report and
	// the share destination data
	if (task?.shareDestination) {
	setParentReport(reports?.[`report_${task.shareDestination}`]);
	const displayDetails = TaskActions.getShareDestination(task.shareDestination, reports, personalDetails);
	setShareDestination(displayDetails);
	}
	// If we have a title, we want to set the title
	if (task?.title !== undefined) {
	setTitle(task.title);
	}
	// If we have a description, we want to set the description
	if (task?.description !== undefined) {
	setDescription(task.description);
	}

It's done like that so the local info is not cleared when the Onyx is cleared.

Also, the task submit button is never disabled even if there is missing info, and instead, all of the info will be validated.

App/src/pages/tasks/NewTaskPage.tsx

Lines 117 to 135 in da700c5

	const onSubmit = () => {
	if (!task?.title && !task?.shareDestination) {
	setErrorMessage(translate('newTaskPage.confirmError'));
	return;
	}
	if (!task.title) {
	setErrorMessage(translate('newTaskPage.pleaseEnterTaskName'));
	return;
	}
	if (!task.shareDestination) {
	setErrorMessage(translate('newTaskPage.pleaseEnterTaskDestination'));
	return;
	}
	playSound(SOUNDS.DONE);
	TaskActions.createTaskAndNavigate(
	parentReport?.reportID ?? '-1',

But, we validate the data/info against the Onyx data which is already cleared, so the missing data error shows even though the page shows the local state.

You might be thinking that we can just validate against the local state, but I personally don't like the idea of not synchronizing the onyx data with what we show to the user. Another downside of doing this is, that even though we show the local state on the confirmation page, pressing the title/description to edit it will show empty on the input field because the onyx is empty.

Money request page: blank screen when onyx data is cleared, submit is disabled when no participant is selected
Task page: task info stays when onyx data is cleared but submitting shows missing info, submit is always enabled

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

blank screen when onyx data is cleared

To fix this, we need to check for both showLoadingPlaceholder and shouldShowListEmptyContent before using renderListEmptyContent.

App/src/components/SelectionList/BaseSelectionList.tsx

Lines 719 to 721 in 36c45f4

	{flattenedSections.allOptions.length === 0 ? (
	renderListEmptyContent()
	) : (

{flattenedSections.allOptions.length === 0 && showLoadingPlaceholder && shouldShowListEmptyContent ? (
    renderListEmptyContent()
) : (

submit is disabled when no participant is selected

I think the expected behavior would be to enable the submit button even when there is no participant selected and show an error when submitting, just like when a merchant is missing. To do that, remove the disable condition here,

App/src/components/MoneyRequestConfirmationList.tsx

Line 841 in da700c5

const shouldDisableButton = selectedParticipants.length === 0;

and show the form error here,

App/src/components/MoneyRequestConfirmationList.tsx

Lines 747 to 756 in da700c5

	const confirm = useCallback(
	(paymentMethod: PaymentMethodType | undefined) => {
	if (iouType === CONST.IOU.TYPE.INVOICE && !hasInvoicingDetails(policy)) {
	Navigation.navigate(ROUTES.MONEY_REQUEST_STEP_COMPANY_INFO.getRoute(iouType, transactionID, reportID, Navigation.getActiveRouteWithoutParams()));
	return;
	}
	if (selectedParticipants.length === 0) {
	return;
	}

if (selectedParticipants.length === 0) {
    setFormError('iou.error.noParticipant');
    return;
}

iou.error.noParticipant is a new error message.

task info stays when onyx data is cleared but submitting shows missing info

For this, we should remove the local state and just rely on the onyx data.

[zanyrenney]

adding the external label.

[melvin-bot]

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

[melvin-bot]

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

[zanyrenney]

Hans - please could you review the proposals above? @hungvu193

[hungvu193]

Hans - please could you review the proposals above? @hungvu193

Sure

[hungvu193]

Will be on my list tmr morning.

[hungvu193]

Hi @NJ-2020, I don't think your solution will cover all the cases, ie when we have a share destination. Also removing this condition can possibly replicate this bug

I also think we should also fix the expense page (we shouldn't show empty view if draft expense was submitted in other tab). Because of that I'm aligned with @bernhardoj 's proposal here

🎀 👀 🎀 C+ reviewed.

[melvin-bot]

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

[bernhardoj]

@francoisl @hungvu193 Can anyone remind me what's the process of getting a new translation?

I currently use this:
en: Please select a participant.
es: Por favor, selecciona un participants.

PR is here

[francoisl]

Let's do:

Por favor, selecciona un participante.

(participante vs. participants) - confirmed with our JaimeGPT translator.

[bernhardoj]

@francoisl sorry, I actually need a confirmation with the new copy too since it's a new message that I add myself.

[francoisl]

Ah, yes Please select a participant also makes sense to me.

[bernhardoj]

Great, thanks!

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

• Fix inconsistent money request and task behavior #50700

If no regressions arise, payment will be issued on 2024-10-30. 🎊

For reference, here are some details about the assignees on this issue:

• @hungvu193 requires payment through NewDot Manual Requests
• @bernhardoj requires payment through NewDot Manual Requests

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@hungvu193] The PR that introduced the bug has been identified. Link to the PR:
• [@hungvu193] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@hungvu193] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@hungvu193] Determine if we should create a regression test for this bug.
• [@hungvu193] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@zanyrenney] Link the GH issue for creating/updating the regression test once above steps have been agreed upon: