Assign Task - Nothing happened when tapping share row on confirm task screen

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.45-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96900
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

Preconditions: logged in to any account that has at least one workspace

Steps:

1. open a workspace chat from the left-hand panel.
2. Tap the compose + → Assign task, enter a Title, then tap Next.
3. On the Confirm task screen, tap the Share row.

Expected Result:

Nothing happened when tapping share row on confirm task screen

Actual Result:

the Share destination page opens (a searchable report list).

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7219243_1785189850996.tap_share.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7219243

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081978841073571831
• Upwork Job ID: 2081978841073571831
• Last Price Increase: 2026-07-28

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/45e13022f5648cb88c9db8c049ce42cf39151e47247800b198b8aa9500305857

[MelvinBot]

Proposal

⚠️ Medium confidence — the root-cause location and the design intent are backed by code, but I could not confirm the exact runtime value of parentReportID on the confirm screen (I can't see the attached video). Flagging the one unverified link explicitly below.

What is the root cause of that problem?

On the Confirm task screen, the Share row is the only row whose interactivity is gated, and it's gated solely on parentReportID:

Code references

• The Share row: DynamicNewTaskPage.tsx:195-203 — interactive={!task?.parentReportID} and shouldShowRightIcon={!task?.parentReportID}.
• Starting "Assign task" from a workspace chat's compose menu sets parentReportID to the current chat: AttachmentPickerWithMenuItems.tsx:357 → Task.ts:1076-1091 (clearOutTaskInfoAndNavigate → setParentReportID).
• MenuItem correctly blocks onPress when interactive is false: MenuItem.tsx:815-816.

The intended design is: a task created from inside a chat (compose + → Assign task) is locked to that chat, so parentReportID is set and the Share row is non-interactive — exactly the tester's "Expected: nothing happens." A task created from global create / FAB has no parentReportID, so the row is interactive and lets you pick a destination.

Since the row still opened the Share destination page, task.parentReportID was falsy on the confirm screen in this flow — i.e., the value set at the start (clearOutTaskInfoAndNavigate) isn't reaching the confirm step. This flow was just migrated to dynamic routes (PR #96900 and #97164), so the draft value likely isn't being carried through the new NEW_TASK → confirm navigation.

Unverified: whether parentReportID (and/or shareDestination) is actually empty at confirm, vs. being present but ignored. That's the one thing to confirm with a quick console check of the TASK Onyx draft on the confirm screen (or from the attached video).

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

1. Confirm the value: log/inspect ONYXKEYS.TASK on the confirm screen right after compose + → Assign task from a workspace chat.
2. If parentReportID is missing there, restore it through the migrated dynamic NEW_TASK navigation so the draft carries it into the confirm step (the pre-migration flow relied on it being present).
3. Make the Share row's interactivity consistent with the value the row already uses to render its destination — task?.shareDestination is the source of truth for icon/title/subtitle, yet interactivity keys off parentReportID. Gating both on the same "locked destination" signal removes this mismatch and prevents a task that already has a fixed destination from ever showing an interactive Share row.

What alternative solutions did you explore? (Optional)

Considered a MenuItem-level fix, but MenuItem already blocks the press correctly when interactive={false} — so the fix belongs on the confirm page's gating value, not the component.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97188) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[huult]

#96900 (comment)

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

On the Confirm task screen the Share row is the only field whose interactivity is conditional, and it is gated entirely on task?.parentReportID:

App/src/pages/tasks/DynamicNewTaskPage.tsx

Lines 195 to 205 in bbb00c6

	<MenuItem
	label={shareDestination?.displayName ? translate('common.share') : ''}
	title={shareDestination?.displayName ?? ''}
	description={shareDestination?.displayName ? shareDestination.subtitle : translate('common.share')}
	iconReportID={task?.shareDestination}
	onPress={() => Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.NEW_TASK_SHARE_DESTINATION.path))}
	interactive={!task?.parentReportID}
	shouldShowRightIcon={!task?.parentReportID}
	titleWithTooltips={shareDestination?.shouldUseFullTitleToDisplay ? undefined : shareDestination?.displayNamesWithTooltips}
	rightLabel={translate('common.required')}
	/>

interactive={!task?.parentReportID} and shouldShowRightIcon={!task?.parentReportID} (lines 201–202). MenuItem refuses to run its onPress while interactive is false:

App/src/components/MenuItem.tsx

Lines 815 to 818 in bbb00c6

	const onPressAction = (event: GestureResponderEvent | KeyboardEvent | undefined) => {
	if (disabled || !interactive) {
	return;
	}

So for the Share destination selector to open on tap (the reported symptom), interactive evaluated to true, which is only possible when task.parentReportID is falsy on the Confirm screen.

Sibling contrast — why parentReportID is the exact discriminator: a task started from inside a chat (compose + → Assign task) is meant to be locked to that chat, so clearOutTaskInfoAndNavigate seeds the draft with the chat's id via setParentReportID (AttachmentPickerWithMenuItems.tsx:357 → Task.ts:1076-1092), and the row is non-interactive — exactly the tester's Expected ("nothing happens"). A task started from global create / FAB has no originating chat, so parentReportID stays empty and the row is interactive by design, so the user can choose (and later re-choose) a destination. The reported state is the chat-origin flow reaching Confirm without its parentReportID, so it behaves like the global-create case: the row shows a destination yet stays tappable.

The fragility lives in how that single locking signal is written. In the same synchronous tick, clearOutTaskInfoAndNavigate mixes Onyx.set and Onyx.merge on the same TASK key — clearOutTaskInfo does Onyx.set(ONYXKEYS.TASK, null):

App/src/libs/actions/Task.ts

Lines 92 to 97 in bbb00c6

	function clearOutTaskInfo(skipConfirmation = false) {
	if (skipConfirmation) {
	Onyx.set(ONYXKEYS.TASK, {skipConfirmation: true});
	} else {
	Onyx.set(ONYXKEYS.TASK, null);
	}

and setParentReportID immediately does Onyx.merge(ONYXKEYS.TASK, {parentReportID}):

App/src/libs/actions/Task.ts

Lines 1068 to 1071 in bbb00c6

	function setParentReportID(parentReportID: string) {
	// This is only needed for creation of a new task and so it should only be stored locally
	Onyx.merge(ONYXKEYS.TASK, {parentReportID});
	}

react-native-onyx explicitly warns that set and merge on the same key don't order like merge-only calls do, and Onyx.set deletes any pending merge for that key before it applies — so the {parentReportID} delta survives only under a favorable interleaving. Compounding this, the row's display (icon/title/subtitle) is driven by a different key, task?.shareDestination (lines 196–199), which is why a draft can reach Confirm displaying a locked-looking destination while parentReportID is empty and the row remains interactive.

Unverified link (stated honestly): the exact interleaving/flow that leaves parentReportID empty at Confirm could not be reproduced at runtime here. Everything above is derived statically; the one thing to confirm from the attached video (or a quick console check of ONYXKEYS.TASK on the Confirm screen) is that parentReportID is empty while shareDestination is populated — which the symptom forces to be true.

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

We should stop mixing Onyx.set and Onyx.merge on the TASK key and seed parentReportID atomically as part of the initial draft, so the Confirm screen's lock signal cannot be dropped:

App/src/libs/actions/Task.ts

Lines 1076 to 1092 in bbb00c6

	function clearOutTaskInfoAndNavigate(
	currentUserAccountID: number,
	assigneePersonalDetails?: OnyxTypes.PersonalDetails,
	reportID?: string,
	chatReport?: OnyxEntry<OnyxTypes.Report>,
	skipConfirmation = false,
	) {
	clearOutTaskInfo(skipConfirmation);
	if (reportID && reportID !== '0') {
	setParentReportID(reportID);
	}
	const assigneeAccountID = assigneePersonalDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID;
	if (assigneePersonalDetails && assigneeAccountID > 0) {
	setAssigneeValue(currentUserAccountID, assigneePersonalDetails, reportID, chatReport, assigneeAccountID === currentUserAccountID, skipConfirmation);
	}
	Navigation.navigate(createDynamicRoute(DYNAMIC_ROUTES.NEW_TASK_DETAILS.path));
	}

-    clearOutTaskInfo(skipConfirmation);
-    if (reportID && reportID !== '0') {
-        setParentReportID(reportID);
-    }
+    const hasParentReport = !!reportID && reportID !== '0';
+    Onyx.set(ONYXKEYS.TASK, {
+        ...(skipConfirmation ? {skipConfirmation: true} : {}),
+        ...(hasParentReport ? {parentReportID: reportID} : {}),
+    });

This is safe because:

• It is a single Onyx.set, so parentReportID is written in the same atomic draft as the reset — there is no longer a set(null)-then-merge() on the TASK key whose result depends on interleaving.
• The downstream setters (setAssigneeValue, setDetailsValue, setShareDestinationValue) still Onyx.merge on top of this draft, so entering the assignee/title/description/destination is unchanged.
• The global-create path passes no reportID, so hasParentReport is false, the draft carries no parentReportID, and the Share row stays interactive there — preserving destination selection via interactive={!task?.parentReportID}.

Note: this keeps the interactivity gate on parentReportID rather than moving it to shareDestination. That is deliberate — shareDestination is populated for both a context-locked destination and a user-picked one, so it cannot distinguish "locked to a chat" from "chosen in global create." Gating on it would lock the row in the global-create flow the instant the user picks a destination.

What alternative solutions did you explore? (Optional)

• Gate the row on task?.shareDestination (or hide it when a destination exists). Rejected: in the global-create flow shareDestination is set as soon as the user picks a destination, so this would lock the row and remove the ability to change it — a regression for that flow, which today intentionally stays editable because parentReportID is empty.
• Force interactive={false} on the Confirm page whenever a destination is shown. Rejected: it papers over the missing parentReportID at the render layer while still breaking the editable global-create case, and leaves the underlying set/merge mix in place for other consumers of the TASK draft.

[suneox]

As mentioned in the comment, this isn't a bug.

[huult]

As mentioned in the comment, this isn't a bug.

@mjasikowski This ticket is not a bug. The issue was caused by incorrect test steps that have since been updated. Could you please close this ticket?

[dilshodmackbook-sketch]

I spent some time on this one and I don't think there's an app bug here, the attached video actually shows the app doing the right thing.

Stepping through the video frame by frame: on the Confirm task screen the tester taps the Share row several times and nothing happens, it stays on Confirm task (URL /r/1360862377662947/task-details/task-confirm). The Share row shows "Applause's Workspace 1" with no chevron, i.e. it's rendered non-interactive. So the recording matches the Expected Result ("nothing happened"), not the Actual Result ("the Share destination page opens"), those two look swapped in the report.

Why the row is intentionally locked here: the task was started from inside a workspace chat (compose + -> Assign task), which sets parentReportID to that chat:

• AttachmentPickerWithMenuItems.tsx#L357 -> Task.ts#L1085-L1086 (clearOutTaskInfoAndNavigate -> setParentReportID).

The Confirm screen then gates the Share row on that value, so a task created from a chat is locked to that chat:

• DynamicNewTaskPage.tsx#L193-L201 - interactive={!task?.parentReportID} and shouldShowRightIcon={!task?.parentReportID}.

And MenuItem correctly blocks the press when interactive is false, which is why the tap is a no-op:

• MenuItem.tsx#L814-L816.

The interactive Share row (where you can pick a destination) only shows when there's no parentReportID, i.e. when the task is started from Global Create rather than from within a chat.

This also isn't a regression from #96900, that PR only swapped the row's onPress navigation target to the dynamic route and left the parentReportID gate untouched. So I agree with @huult that the right fix is to correct the QA precondition (start the task from Global Create to exercise the interactive Share destination), rather than to change app code.