Skip to content

[No QA] Docs updates for E/A#96458 in-app camera for chat attachment photos - #101478

Open
MelvinBot wants to merge 2 commits into
mainfrom
claude-docsInAppCameraChatAttachments
Open

MelvinBot wants to merge 2 commits into
mainfrom
claude-docsInAppCameraChatAttachments

Conversation

@MelvinBot

Copy link
Copy Markdown
Contributor

Explanation of Change

Help site follow-up for fix: use in-app VisionCamera for chat attachment photos (re-land).

That PR replaced the external system camera with an in-app VisionCamera modal when a member taps Take photo in the chat attachment picker, so Expensify stays in the foreground during capture. The in-app camera screen has its own controls (close, flash, shutter, flip camera) and its own camera-permission prompt, none of which were documented.

docs/articles/new-expensify/chat/Chat-Features-and-Moderation-Tools.md previously described the mobile flow only as "Use the message bar to type a message, add an attachment, or insert an emoji" — it never named the attachment options and never mentioned a camera.

Changes in this PR (one file):

  1. Named the mobile attachment options. The mobile sending steps now match the web steps in structure and name the three picker options in the order the app shows them: Take photo, Choose from gallery, Choose file.
  2. Added a new ## How to take a photo to attach to a chat message section covering the in-app camera: the camera permission prompt and its Continue button, the flash icon (left), shutter button (center), and flip camera icon (right), the X to close, and the fact that flash and flip camera are hidden when the device lacks a flash or a second camera.
  3. Stated the platform difference explicitly. The in-app camera is mobile app only; on web and mobile web Add attachment opens the device file picker.
  4. Corrected the composer placeholder from Write something to Write something... to match the live UI.
  5. Added add attachment, take photo, and in-app camera keywords so the article is retrievable for these searches.

How UI labels were verified

  • Web labels were checked against the live app: the composer placeholder is Write something..., and the + menu shows Create expense, Track distance, Split expense, Pay Expensify, Assign task, Add attachment — with no Take photo option, confirming the in-app camera is native-only.
  • Native picker labels and order come from the merged code: the menu is built as Take photo, Choose from gallery, Choose file.
  • Camera control positions (close top-right, flash left, shutter center, flip camera right) and the Continue permission button come from the merged AttachmentCamera layout.

What was reviewed and left unchanged

  • docs/articles/new-expensify/reports-and-expenses/Attach-and-edit-receipts-on-expenses.md, Create-an-Expense.md, Track-Expenses.md, and Track-Personal-Expenses.md describe the receipt-scanning camera, which already used an in-app camera and is not changed by the linked PR.
  • The flip camera string added in the linked PR is an accessibility label, not visible on-screen text, so it is documented as an icon rather than a button label.

Tests

Documentation only — no code changes, so there is nothing to test in the app. Verified the Markdown renders correctly and the article still uses only # and ## headings.

  • Verify that no errors appear in the JS console

Offline tests

Not applicable — documentation only.

QA Steps

  1. Open the help site article Chat Features and Moderation Tools.
  2. Confirm the Sending Messages mobile steps name Take photo, Choose from gallery, and Choose file.
  3. Confirm the new How to take a photo to attach to a chat message section appears and its steps match the in-app camera on a native build.
  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
  • I verified there are no console errors

Screenshots/Videos

Documentation only — no UI changes.


@ShridharGoel, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying @MelvinBot mark this PR as ready for review.

Co-authored-by: Shridhar Goel <ShridharGoel@users.noreply.github.com>
@MelvinBot MelvinBot added the HelpDot Apply this label if the issue relates to ExpensifyHelp label Sep 17, 2026
@github-actions github-actions Bot changed the title Docs updates for E/A#96458 in-app camera for chat attachment photos [No QA] Docs updates for E/A#96458 in-app camera for chat attachment photos Sep 17, 2026
@OSBotify

This comment has been minimized.


## How to take a photo to attach to a chat message

In the Expensify mobile app, **Take photo** opens a camera inside Expensify, so you stay in the app while you capture the photo. On web and mobile web, **Add attachment** opens your device's file picker instead, so there is no in-app camera.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MelvinBot This shouldn't be needed

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed — removed. Whether the camera is in-app or the system picker is an implementation detail, not something a reader needs.

Instead of explaining the platform difference in prose, I folded it into the heading using the existing house convention (## ... (Mobile only), as in Create-an-Expense.md:73 and Distance-Expenses.md:14):

-## How to take a photo to attach to a chat message
-
-In the Expensify mobile app, **Take photo** opens a camera inside Expensify, so you stay in the app while you capture the photo. On web and mobile web, **Add attachment** opens your device's file picker instead, so there is no in-app camera.
+## How to take a photo to attach to a chat message (Mobile only)

I also dropped the now-orphaned in-app camera keyword from the front matter, since the article no longer uses that term.

Pushed as 017e395 — see Chat-Features-and-Moderation-Tools.md:33.

Let me know if you'd rather cut the whole section, or trim the flash/flip-camera detail in steps 5 and 7 too.

Co-authored-by: Shridhar Goel <ShridharGoel@users.noreply.github.com>
@ShridharGoel

Copy link
Copy Markdown
Contributor

@MelvinBot Mark as ready

@OSBotify

Copy link
Copy Markdown
Contributor

A preview of your ExpensifyHelp changes have been deployed to https://23114bdc.helpdot.pages.dev ⚡️

Updated articles:

@MelvinBot

Copy link
Copy Markdown
Contributor Author

There's nothing to fix in the code — every automated check on this PR passes.

The one failing check, Check independent approval, fails because no one has approved the PR yet, not because of anything in the diff:

approvers: [],
independentApprovers: [],
##[error]Expensify/App#101478 does not have enough independent eligible reviewer approvals.

It will go green once an eligible reviewer other than the author approves.

Full check status
Check Result
build (Deploy ExpensifyHelp) ✅ pass
spellcheck ✅ pass
verify (Validate Docs Routes File) ✅ pass
check (validateCode terminology) ✅ pass
validate / CLA ✅ pass
verifySignedCommits ✅ pass
checklist ✅ pass
Check independent approval ❌ fail — needs a reviewer approval

build was still in progress when this request came in; it has since finished successfully, so the help-site deploy is not a problem either.

Next step: this PR is still a draft. Reply with @MelvinBot mark this PR as ready for review once you've confirmed the doc changes, then a reviewer approval will clear the last check.


view run

@ShridharGoel

Copy link
Copy Markdown
Contributor

Reviewer Checklist

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
  • I verified tests pass on all platforms & I tested again on:
    • Android: HybridApp
    • Android: mWeb Chrome
    • iOS: HybridApp
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If any new file was added I verified that:
    • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
    • I verified that all the inputs inside a form are aligned with each other.
    • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
  • For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp
Android: mWeb Chrome
iOS: HybridApp
iOS: mWeb Safari
MacOS: Chrome / Safari

@MelvinBot
MelvinBot marked this pull request as ready for review September 18, 2026 05:06
@MelvinBot

Copy link
Copy Markdown
Contributor Author

Done — this PR is now marked Ready for review.

Current check status on 017e395: all substantive checks pass, including spellcheck, build, verify, and verifySignedCommits. The only failing check is Check independent approval, which is expected until a reviewer approves.

This also confirms the earlier cleanup is clean — spellcheck passed, which I couldn't run locally.

2. Tap the **plus icon**, then select **Add attachment**.
3. Tap **Take photo**.
4. If Expensify asks for camera access, tap **Continue**, then allow camera access on your device.
5. Tap the **flash** icon on the left to turn the flash on or off, or the **flip camera** icon on the right to switch between the front and back cameras.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Step formatting: This numbered step bundles two distinct optional actions (toggling flash and using flip camera) into one step. Per HELP_AUTHORING_GUIDELINES.md Section 5, steps should be sequential and action-oriented (one action per step). Consider splitting into two steps, or moving these optional controls out of the numbered sequence since they are not required to complete the capture.

@github-actions

Copy link
Copy Markdown
Contributor

HelpDot Documentation Review

Overall Assessment
This PR makes focused, high-quality updates to Chat-Features-and-Moderation-Tools.md: it aligns the mobile sending steps with the web steps, names the three attachment picker options, corrects the composer placeholder, adds targeted keywords, and introduces a new task-based section documenting the in-app camera. The changes are accurate, concise, and largely compliant with the governance files.

Scores Summary

  • Readability: 9/10 - Steps are sequential, action-oriented, and scannable. The new camera section reads clearly and follows a logical capture-then-review flow.
  • AI Readiness: 8/10 - The new heading ## How to take a photo to attach to a chat message (Mobile only) is a strong task-based, searchable How-to heading, and the new keywords (add attachment, take photo) reflect real search intent. Only valid heading levels are used in the diff. Minor: the mobile-only nature is conveyed in the heading suffix rather than an explicit scope statement.
  • Style Compliance: 8/10 - UI labels (Take photo, Choose from gallery, Choose file, Continue, Add attachment, Send, X) are bolded and match the UI, and the placeholder fix to Write something... is a good catch. Icons (flash, flip camera) are correctly described as icons since flip camera is an accessibility label. Minor gap noted below on cross-platform phrasing.

Key Findings

  • Positive: Mobile steps now mirror the web steps in structure and explicitly name the picker options in UI order, a clear improvement in parity and precision.
  • Positive: New section is single-workflow, task-based, and uses UI-exact labels throughout.
  • Minor: The PR description states web / mobile web opens the device file picker, but the article body does not explicitly state this platform difference. The Cross-Platform Clarity Rule prefers an explicit statement (that the in-app camera is native app only and web/mobile web opens the file picker) rather than relying solely on the (Mobile only) heading suffix.
  • Minor: Step 7 (Review the photo in the preview, then send it to the chat) is slightly less deterministic than the surrounding steps; naming the confirm/send control would tighten it.

Recommendations

  • Add one explicit sentence clarifying that the in-app camera is available in the mobile app only and that on web and mobile web Add attachment opens the device file picker.
  • Optionally make the preview/send step reference the exact on-screen control to match the Deterministic Writing Rule.

Files Reviewed

  • docs/articles/new-expensify/chat/Chat-Features-and-Moderation-Tools.md - Approved with minor suggestions; changes are accurate and compliant with governance.

Note: Detailed line-by-line feedback has been provided as inline comments.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 017e395fa2

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

4. If Expensify asks for camera access, tap **Continue**, then allow camera access on your device.
5. Tap the **flash** icon on the left to turn the flash on or off, or the **flip camera** icon on the right to switch between the front and back cameras.
6. Tap the **shutter** button in the center to capture the photo.
7. Review the photo in the preview, then send it to the chat.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Remove the nonexistent native preview step

After the shutter is tapped in the native chat flow, AttachmentCamera passes the photo to handleCameraCapture, and useAttachmentPicker immediately calls addAttachment() and clearComposer(), which submits the attachment; no review screen or separate send action is shown. Telling users to review the photo and then send it therefore describes controls they cannot access and should be replaced with the actual automatic-send behavior.

Useful? React with 👍 / 👎.

2. Use the message bar to type a message, add an attachment, or insert an emoji.
3. Tap the **Send** icon.
2. Tap the field labeled **Write something...**, then type your message.
3. To add an attachment, tap the **plus icon**, select **Add attachment**, then choose **Take photo**, **Choose from gallery**, or **Choose file**.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Limit these attachment options to the native app

This instruction is not valid for users accessing Expensify from a mobile browser: the web/mobile-web AttachmentPicker uses a hidden file input directly and never renders the Take photo, Choose from gallery, and Choose file menu. Since the article elsewhere distinguishes mobile web from the native mobile app, label this flow as native-app-only (and clarify that mobile web opens the device file picker) so mobile-web users are not directed to nonexistent options.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

HelpDot Apply this label if the issue relates to ExpensifyHelp

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants