[$250] [Exploratory] 91626-Chat-In a Read only conversation, user can add attachment

[applause-bot]

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: V9.3.99
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-38470/folder/13177075/41237842/1461645418
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Open 1:1 chat
3. Create a manual expense with a receipt
4. Open the expense
5. Invite a user sending @email id
6. From whisper, select invite to chat
7. As invited user login & open the expense
8. On the receipt, tap plus and take a camera image
9. Note camera image is added to conversation

Expected Result:

In a Read only conversation, user must not be able to add attachment

Actual Result:

In a Read only conversation, user can add attachment

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7171477_1780572466489.Screenrecorder-2026-06-04-16-48-07-170.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7171477

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078168130311692737
• Upwork Job ID: 2078168130311692737
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @wildan-m

[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/67471738fae2bc9fb9d643c4878782ca9dee7f416cb3f435a6793571b576cd23

[MelvinBot]

Proposal

What is the root cause of that problem?

The "+" Add additional receipt button on the receipt is gated only by a generic "can I write in this chat?" check, not by the receipt‑edit permission that every other receipt action uses.

In MoneyRequestReceiptView.tsx:541 the button's visibility is:

const canShowReceiptActions = hasReceipt && !isLoading && isEditable && !mergeTransactionID;

where isEditable is just canUserPerformWriteAction(report) && !readonly.

For a user who was invited to the chat but is not the expense requestor, canUserPerformWriteAction returns true (they are allowed to comment in the DM), so isEditable is true and the "+" button renders. Pressing it calls addAttachmentWithComment, which posts the image into the conversation — exactly the reported behavior ("camera image is added to conversation").

The receipt‑specific permission canEditReceipt is already computed in this component (line 247 — it runs canEditFieldOfMoneyRequest({fieldToEdit: RECEIPT, …}), which requires the current user to be the requestor/manager/admin). That user fails canEditReceipt. The receipt image itself and the Expand button correctly respect it (readonly={readonly || !canEditReceipt} at line 687 and line 742) — but canShowReceiptActions for the "+" button does not. That inconsistency is the bug.

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

Include canEditReceipt in the canShowReceiptActions condition at MoneyRequestReceiptView.tsx:541 so the "+" Add‑additional‑receipt button uses the same receipt‑edit permission as the receipt image and Expand button. A user who cannot edit the receipt will then no longer see (or be able to trigger) the add‑attachment action, matching the expected read‑only behavior.

Investigation details & alternatives considered

• Why the generic gate is too weak here: canUserPerformWriteAction → canWriteInReport only reflects chat commenting rights, and additionally defaults to writable when report.permissions is empty. It says nothing about who may edit the expense/receipt. canEditReceipt (via canEditFieldOfMoneyRequest → canEditMoneyRequest in ReportUtils.ts) is the check that restricts receipt edits to the requestor/manager/admin, which is what should gate this button.
• Alternative (defense in depth): the underlying actions addAttachmentWithComment (libs/actions/Report/index.ts) and replaceReceipt (libs/actions/IOU/Receipt.ts) perform no write‑access re‑validation, so the UI gate is the only client‑side protection. Server‑side enforcement would be the robust backstop, but the minimal client fix above resolves the reported UX.
• Confidence: Medium‑high. Code path is confirmed; the exact runtime value of canEditReceipt for the invited user (expected false for a non‑requestor on an IOU report) is inferred from the code and worth a quick confirmation during implementation/testing.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92679) 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 - @Krishna2323 (External)

[wildan-m]

Proposal

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

In a read-only conversation, a user who cannot write in the conversation is still able to add an attachment to an expense. Opening the expense and using the "add additional receipt" (+) button on the receipt lets the user attach a camera image, which is posted to the conversation. The expected behavior is that a user who cannot write in a read-only conversation must not be able to add an attachment.

What is the root cause of that problem?

A read-only conversation enforces its restriction on the conversation (chat) report — through that report's permissions / writeCapability. The conversation's own composer correctly respects this because ReportFooter hides the composer based on canUserPerformWriteAction evaluated against the chat report:

App/src/pages/inbox/report/ReportFooter.tsx

Lines 76 to 77 in 8ea16a6

	const canPerformWriteAction = canUserPerformWriteAction(report, isReportArchived) ?? shouldShowComposerOptimistically;
	const shouldHideComposer = !canPerformWriteAction || isBlockedFromChat;

The expense receipt view, however, derives its editability from the wrong report. In MoneyRequestReceiptView, the isEditable flag is computed only from canUserPerformWriteAction(report), where report is the transaction thread report (the expense detail), not the parent conversation report:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 216 to 217 in 8ea16a6

	const isReportArchived = useReportIsArchived(report?.reportID);
	const isEditable = !!canUserPerformWriteActionReportUtils(report, isReportArchived) && !readonly;

The transaction thread report does not carry the conversation's read-only restriction, so canUserPerformWriteAction returns true for it (canWriteInReport returns true when the report has no restricting permissions):

App/src/libs/ReportUtils.ts

Lines 2436 to 2442 in 8ea16a6

	function canWriteInReport(report: OnyxEntry<Report>): boolean {
	if (Array.isArray(report?.permissions) && report?.permissions.length > 0 && !report?.permissions?.includes(CONST.REPORT.PERMISSIONS.AUDITOR)) {
	return report?.permissions?.includes(CONST.REPORT.PERMISSIONS.WRITE);
	}
	return true;
	}

Because isEditable is true, the receipt action buttons are shown via canShowReceiptActions:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Line 509 in 8ea16a6

const canShowReceiptActions = hasReceipt && !isLoading && isEditable && !isMapDistanceRequest && !mergeTransactionID;

and the add-attachment (+) button posts the attachment to the conversation through addAttachmentWithComment, even though the current user cannot write in that conversation:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Lines 645 to 684 in 8ea16a6

	{canShowReceiptActions && (
	<View style={[styles.receiptActionButtonsContainer, styles.pointerEventsBoxNone, !hovered && !isPickerOpen && deviceHasHoverSupport && styles.opacity0]}>
	<AttachmentPicker acceptedFileTypes={[...CONST.API_ATTACHMENT_VALIDATIONS.ALLOWED_RECEIPT_EXTENSIONS]}>
	{({openPicker}) => (
	<Tooltip text={translate('receipt.addAdditionalReceipt')}>
	<PressableWithoutFeedback
	ref={addButtonRef}
	onPress={() => {
	setIsPickerOpen(true);
	resetButtonHoverState(addButtonRef);
	const onPickerClosed = () => {
	setIsPickerOpen(false);
	if (isElementHovered(receiptContainerRef)) {
	hoverBind.onMouseEnter();
	}
	};
	openPicker({
	onPicked: (files) => {
	onPickerClosed();
	validateFiles(files, undefined, {isValidatingReceipts: false});
	},
	onCanceled: onPickerClosed,
	});
	}}
	style={styles.receiptActionButton}
	hoverStyle={styles.buttonDefaultHovered}
	accessibilityLabel={translate('receipt.addAdditionalReceipt')}
	role={CONST.ROLE.BUTTON}
	sentryLabel={CONST.SENTRY_LABEL.RECEIPT.ADD_ATTACHMENT_BUTTON}
	>
	<Icon
	src={lazyIcons.ReceiptPlus}
	height={variables.iconSizeSmall}
	width={variables.iconSizeSmall}
	fill={theme.icon}
	/>
	</PressableWithoutFeedback>
	</Tooltip>
	)}
	</AttachmentPicker>

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

Make the receipt view's editability conversation-aware, so it mirrors how the conversation's composer is gated.

In MoneyRequestReceiptView, in addition to the existing canUserPerformWriteAction(report) check used to compute isEditable, also require that the current user can write in the parent conversation (chat) report. The component already loads the chat report and computes its archived state:

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Line 139 in 8ea16a6

const [chatReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${getNonEmptyStringOnyxID(parentReport?.parentReportID)}`);

App/src/components/ReportActionItem/MoneyRequestReceiptView.tsx

Line 179 in 8ea16a6

const isChatReportArchived = useReportIsArchived(moneyRequestReport?.chatReportID);

So isEditable (line 217) should additionally require canUserPerformWriteAction(chatReport, isChatReportArchived) to be true when a chat report is present. Guard the new condition on the chat report being available, so contexts where there is no parent conversation report (or while data is still loading) are unaffected.

With this change, canShowReceiptActions becomes false for a user who cannot write in the read-only conversation, so the add-attachment (+) button is hidden and the attachment write through addAttachmentWithComment is no longer reachable — matching how ReportFooter already hides the conversation composer for the same user. This also keeps the other edit affordances guarded by isEditable consistent with the read-only conversation.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92679-readonly-receipt-attachment?expand=1

What alternative solutions did you explore? (Optional)

• Gate only the add-attachment button (i.e. canShowReceiptActions) on the conversation write permission rather than folding it into isEditable. This fixes the reported symptom but leaves the remaining edit affordances inconsistent with the read-only conversation, so extending isEditable is the cleaner, more complete fix.
• Add the write-permission check inside the attachment-add handler (onAttachmentFilesValidated) instead of the visibility check. This would block the write but still display a non-functional (+) button to the user, which is a worse experience than hiding the control.