Skip to content

Add workspace rules PDF document upload, view, and management UI#87684

Open
ishpaul777 wants to merge 18 commits intoExpensify:mainfrom
ishpaul777:ishpaul/workspace-rules-document-upload
Open

Add workspace rules PDF document upload, view, and management UI#87684
ishpaul777 wants to merge 18 commits intoExpensify:mainfrom
ishpaul777:ishpaul/workspace-rules-document-upload

Conversation

@ishpaul777
Copy link
Copy Markdown
Contributor

@ishpaul777 ishpaul777 commented Apr 11, 2026

Explanation of Change

Adds frontend support for workspace admins to upload, replace, view, and delete a PDF rules document on the workspace overview page. Non-admins can view/download the document. This is the frontend (App) portion of a multi-repo change.

Key changes:

  • New rulesDocumentURL field on the Policy Onyx type
  • updatePolicyRulesDocument / deletePolicyRulesDocument action functions with optimistic/failure/finally Onyx updates
  • PDF thumbnail preview with three-dots menu (replace/remove) overlaid on thumbnail with circular background
  • Full-screen PDF viewer via WORKSPACE_DOCUMENT route and WorkspaceDocumentModalContent
  • getRulesDocumentSourceURL utility routing remote URLs through authenticated GetPolicyRulesDocument streaming endpoint with cache-busting
  • Translation keys added to all 3 locales (en, zh-hans, pt-BR)

Key decisions:

  • Field named rulesDocumentURL (not policyDocumentURL) — policy prefix is redundant inside a policy object
  • Optimistic updates use file.uri (local blob URL) for instant display — same pattern as workspace avatar
  • Cache-busting via &cacheBuster= encoding the full rulesDocumentURL — ensures unique streaming URL per PDF version
  • Dedicated WORKSPACE_DOCUMENT route instead of reusing REPORT_ATTACHMENTS
  • PDF served through authenticated streaming endpoint for CORS compatibility with pdfjs and privacy (private S3 bucket)

Companion PRs:

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/610806

Tests

  1. Navigate to workspace overview (Settings > Workspaces > [workspace] > Overview)
  2. As admin: scroll to "Expense policy" section, click "Choose file", select a PDF
  3. Verify PDF thumbnail renders with three-dots menu overlaid (circular white background, top-right)
  4. Click thumbnail to open full-screen PDF viewer — verify it loads correctly
  5. Use three-dots > Replace to upload a different PDF — verify thumbnail updates immediately (optimistic)
  6. Use three-dots > Remove — verify thumbnail disappears and "Choose file" button returns
  7. Try uploading a non-PDF file — verify error is shown
  8. As non-admin member: verify the thumbnail is visible and clickable (view-only), three-dots menu is hidden
  9. Verify the "Policy text" field (custom rules text input) still works as before
  • Verify that no errors appear in the JS console

Offline tests

QA Steps

  1. Navigate to a workspace overview page
  2. Upload a PDF rules document as an admin
  3. Verify PDF thumbnail renders correctly with three-dots overlay
  4. Replace the document, verify the new PDF loads
  5. Remove the document, verify it clears
  6. As a non-admin, verify the document is viewable but not editable
  • 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 added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover 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 tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android: Native
    • Android: mWeb Chrome
    • iOS: Native
    • iOS: mWeb Safari
    • MacOS: Chrome / Safari
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (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 shown in the product is localized by adding it to src/languages/* files and using the translation method
      • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
    • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
    • 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)
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
  • I verified that if a function's arguments changed that all usages have also been updated correctly
  • 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 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.
  • I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user 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.

Screenshots/Videos

Android: Native
Android: mWeb Chrome
iOS: Native
Screen.Recording.2026-04-16.at.1.10.39.AM.mov
iOS: mWeb Safari
Screen.Recording.2026-04-16.at.1.10.02.AM.mov
MacOS: Chrome / Safari
Screen.Recording.2026-04-15.at.11.42.24.PM.mov
Screen.Recording.2026-04-15.at.11.42.24.PM.mov

@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 11, 2026

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines Coverage Δ
src/CONST/index.ts 92.30% <ø> (ø)
src/SCREENS.ts 100.00% <ø> (ø)
src/libs/API/types.ts 100.00% <ø> (ø)
src/libs/Navigation/AppNavigator/AuthScreens.tsx 83.51% <100.00%> (+0.18%) ⬆️
...ateRootStackNavigator/GetStateForActionHandlers.ts 19.23% <ø> (ø)
src/libs/Navigation/linkingConfig/config.ts 76.92% <ø> (ø)
...ntModalScreen/AttachmentModalBaseContent/index.tsx 88.37% <100.00%> (-1.17%) ⬇️
src/styles/variables.ts 100.00% <ø> (ø)
src/ROUTES.ts 16.97% <0.00%> (-0.02%) ⬇️
src/pages/media/AttachmentModalScreen/index.tsx 25.00% <0.00%> (-2.78%) ⬇️
... and 5 more
... and 4 files with indirect coverage changes

@JmillsExpensify
Copy link
Copy Markdown
Contributor

I'd like to review this PR when the time comes, so going to add myself proactively.

@JmillsExpensify JmillsExpensify self-requested a review April 13, 2026 10:36
@ishpaul777 ishpaul777 force-pushed the ishpaul/workspace-rules-document-upload branch from 159f567 to 340ab6f Compare April 15, 2026 18:16
@melvin-bot
Copy link
Copy Markdown

melvin-bot Bot commented Apr 15, 2026

Hey, I noticed you changed src/languages/en.ts in a PR from a fork. For security reasons, translations are not generated automatically for PRs from forks.

If you want to automatically generate translations for other locales, an Expensify employee will have to:

  1. Look at the code and make sure there are no malicious changes.
  2. Run the Generate static translations GitHub workflow. If you have write access and the K2 extension, you can simply click: [this button]

Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running:

npx ts-node ./scripts/generateTranslations.ts --help

Typically, you'd want to translate only what you changed by running npx ts-node ./scripts/generateTranslations.ts --compare-ref main

@ishpaul777
Copy link
Copy Markdown
Contributor Author

@MelvinBot please review that this follows our code style and patterns

@MelvinBot
Copy link
Copy Markdown
Contributor

Overall the PR follows our code style and patterns well — the Onyx optimistic/failure/finally structure, navigation wiring, modal content architecture, and API parameter types all match established conventions. A few things worth addressing:

1. getRulesDocumentMenuItems is not memoized — This function is defined inline in the component body and creates new array/object references on every render. Since it's passed to ThreeDotsMenumenuItems, this can cause unnecessary re-renders. Consider wrapping it with useMemo (or making the menu items a memoized value) similar to how other menu item arrays are handled in workspace pages.

2. Inline style objects on every render — These create new object references each render:

style={{width: variables.rulesDocumentThumbnailWidth, height: variables.rulesDocumentThumbnailHeight}}

and

{top: variables.spacing2, right: variables.spacing2}

and

{borderRadius: variables.componentSizeNormal / 2, backgroundColor: theme.cardBG}

Consider extracting these to useMemo or StyleSheet.create outside the render path, or adding them as named styles in the theme styles file.

3. as File type assertionfiles.at(0) as File appears twice. If FileObject doesn't fully align with File, this could silently mask type mismatches. Check whether the API parameter type (UpdatePolicyRulesDocumentParams) should use FileObject instead of File to avoid the cast.

4. Minor — The eslint-disable-next-line rulesdir/no-negated-variables in WorkspaceDocumentModalContent.tsx for shouldShowNotFoundPage could be avoided by renaming to something like isValidDocument and inverting the logic.

Everything else (translations, route/screen registration, AttachmentPicker usage, OfflineWithFeedback wrapping, PDFThumbnail rendering, the authenticated streaming URL pattern) looks good and consistent with codebase conventions.

@ishpaul777 ishpaul777 marked this pull request as ready for review April 15, 2026 19:19
@ishpaul777 ishpaul777 requested review from a team as code owners April 15, 2026 19:19
@melvin-bot melvin-bot Bot requested review from abzokhattab and flaviadefaria and removed request for a team and flaviadefaria April 15, 2026 19:19
@melvin-bot
Copy link
Copy Markdown

melvin-bot Bot commented Apr 15, 2026

@abzokhattab Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@melvin-bot melvin-bot Bot removed the request for review from a team April 15, 2026 19:19
@shawnborton
Copy link
Copy Markdown
Contributor

I think the modal title should match the label that we use above the thumbnail (which is "Policy document"):
CleanShot 2026-04-15 at 21 24 21@2x

Copy link
Copy Markdown

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

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

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +865 to +869
onPicked: (files) => {
if (!policyID || !files.length) {
return;
}
updatePolicyRulesDocument(policyID, files.at(0) as File, policy?.rulesDocumentURL);
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 Validate rules document type before sending upload

The selected file is sent directly to updatePolicyRulesDocument without checking MIME/extension, which means iOS/Android can submit non-PDF files here (native AttachmentPicker does not enforce acceptedFileTypes and uses types.allFiles for FILE mode). In that case the command may upload invalid content or fail server-side, breaking the “PDF rules document” flow for mobile users.

Useful? React with 👍 / 👎.

subtitleTextStyles={[styles.textNormal, styles.colorMuted, styles.mr5]}
containerStyles={shouldUseNarrowLayout ? styles.p5 : styles.p8}
>
<OfflineWithFeedback pendingAction={policy?.pendingFields?.rulesDocumentURL}>
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 Show rules document upload failures in the UI

This wrapper only tracks pendingAction, but the new actions write failures into policy.errorFields.rulesDocumentURL. Because errors/onClose are not wired here, failed uploads/deletes silently revert with no visible feedback, so users cannot tell why the document update failed (e.g., rejected file type, network/server error).

Useful? React with 👍 / 👎.

@ishpaul777 ishpaul777 force-pushed the ishpaul/workspace-rules-document-upload branch from c41aa38 to a79a1df Compare April 15, 2026 19:54
@ishpaul777
Copy link
Copy Markdown
Contributor Author

I think the modal title should match the label that we use above the thumbnail (which is "Policy document"):

fixed

Screenshot 2026-04-16 at 1 24 17 AM

@shawnborton
Copy link
Copy Markdown
Contributor

Thanks! Will run a test build now 🚀

@ishpaul777
Copy link
Copy Markdown
Contributor Author

@shawnborton BE is not merged so upload will not work right now 😅 will have to wait for BE PRs to be merged

meanwhile here are screenshots


👤 Employee

State Screenshot
No Document, Text No Document, Text
Document, No Text Document, No Text
Both (Document + Text) Both
No Document, No Text No Doc No Text

🛠️ Admin

State Screenshot
Both (Document + Text) Both
No Text No Text
No Document, Text No Document, Text
No Document, No Text Screenshot 2026-04-16 at 1 46 13 AM

@abzokhattab
Copy link
Copy Markdown
Contributor

@MelvinBot Review the PR

@abzokhattab
Copy link
Copy Markdown
Contributor

@codex review

@MelvinBot
Copy link
Copy Markdown
Contributor

PR Review

Overall this is well-structured and follows existing codebase patterns (Onyx optimistic/failure/finally, navigation wiring, OfflineWithFeedback with error fields). A few items to address:

Issues

1. getRulesDocumentMenuItems recreates arrays every render
getRulesDocumentMenuItems is called inline inside the render tree (menuItems={getRulesDocumentMenuItems(openPicker)}), producing new array/object references on each render. Since openPicker comes from a render prop this can't trivially be memoized with useMemo, but wrapping it in useCallback + moving the array construction into a useMemo keyed on stable deps (or memoizing ThreeDotsMenu items inside the render-prop body) would avoid unnecessary re-renders of ThreeDotsMenu.

2. as File type assertion
file as File at the call site assumes FileObject is always a File. On web this is usually true, but on native FileObject can be a ReactNativeFile or similar. Consider typing UpdatePolicyRulesDocumentParams.file as FileObject instead, which is what the API layer already handles for file uploads (see UpdateWorkspaceAvatarParams). This removes the cast and avoids a potential runtime mismatch on native.

3. Section visibility condition is complex — consider extracting

isBetaEnabled(CONST.BETAS.CUSTOM_RULES) && (isPolicyAdmin || !!policy?.rulesDocumentURL || !StringUtils.isEmptyString(policy?.customRules ?? ''))

This condition is evaluated once but is hard to parse at a glance. A named boolean (e.g. const shouldShowExpensePolicySection = ...) would improve readability.

4. Minor: eslint-disable for no-negated-variables
In WorkspaceDocumentModalContent.tsx, shouldShowNotFoundPage triggers the lint rule. Renaming to isDocumentAvailable (inverted) removes the need for the disable comment and reads more naturally.

Looks good

  • Optimistic/failure/finally Onyx structure matches deleteWorkspaceAvatar/updateWorkspaceAvatar exactly
  • PDF validation (isPDF check) is done client-side before sending the API call — good
  • Error fields are properly wired into OfflineWithFeedback with errors + onClose (the codex-bot comment about missing error wiring is outdated — it's been added)
  • Cache-busting via cacheBuster param encoding the full S3 URL is a clean approach
  • Translation keys added across all locales
  • Route/screen/navigation registration follows established patterns
  • useMemo for inline styles (thumbnail, menu position, icon) — addresses the earlier review feedback

Copy link
Copy Markdown

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

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: 4ba51e224d

ℹ️ 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".

Comment on lines +31 to +38
const contentProps = useMemo<AttachmentModalBaseContentProps>(
() => ({
source: rulesDocumentSourceURL,
headerTitle: translate('workspace.rules.customRules.policyDocument'),
originalFileName: `${policyID}-policy-document.pdf`,
shouldShowNotFoundPage,
isLoading,
shouldCloseOnSwipeDown: true,
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 Wire a download action into workspace document modal

WorkspaceDocumentModalContent only passes source/metadata and never provides an onDownloadAttachment path (or a context that enables the built-in download control), so the new policy PDF is effectively view-only in-app. In AttachmentModalBaseContent, the header download button is gated by that callback/context, which means members cannot reliably download the rules document from this screen (especially on native, where browser save controls are unavailable).

Useful? React with 👍 / 👎.

@shawnborton
Copy link
Copy Markdown
Contributor

Okay that looks pretty good, but let us know when the BE is ready so we can test with adhoc builds. Thanks!

@ishpaul777
Copy link
Copy Markdown
Contributor Author

ishpaul777 commented Apr 21, 2026

@shawnborton @abzokhattab BE PRs merged and deployed, can we trigger Adhoc build

@abzokhattab
Copy link
Copy Markdown
Contributor

I have two weird issues..

On iOS when clicking on replace nothing happens ... also after uploading the PDF and opening it .. it keeps reloading ... is it the same for you?

Screen.Recording.2026-04-22.at.16.27.30.mov
Screen.Recording.2026-04-22.at.16.28.33.mov

@ishpaul777
Copy link
Copy Markdown
Contributor Author

@MelvinBot please investigate the all issues pointed out

@MelvinBot
Copy link
Copy Markdown
Contributor

Here's my investigation of all four issues raised on this PR:


1. Validate rules document type before sending upload (Codex P2)

Verdict: Already handled, but UX could be better on native.

There is a post-pick PDF validation in updatePolicyRulesDocument (Policy.ts:1809-1816) that checks MIME type and file extension. If a non-PDF is selected, it writes an error to errorFields.rulesDocumentURL and aborts the upload — so invalid files are never sent to the server.

On web, acceptedFileTypes={['pdf']} restricts the OS file dialog to .pdf files (WorkspaceOverviewPage.tsx:837), so the user can't even pick a non-PDF.

On native, the AttachmentPicker ignores acceptedFileTypes and hard-codes types.allFiles (index.native.tsx:254-255). Users can select any file type, then see a post-pick error. This matches abzokhattab's comment — the native picker doesn't forward acceptedFileTypes. This is a UX gap (not a bug), since the server-side check + client-side validation in the action function prevent any data corruption.


2. Show rules document upload failures in the UI (Codex P2)

Verdict: Not an issue — errors are already wired up.

The OfflineWithFeedback wrapper at WorkspaceOverviewPage.tsx:826-834 correctly reads:

  • pendingAction from policy.pendingFields.rulesDocumentURL
  • errors from getLatestErrorField(policy, 'rulesDocumentURL')
  • onClose calls clearPolicyErrorField(policyID, 'rulesDocumentURL')

Both updatePolicyRulesDocument (Policy.ts:1844-1852) and deletePolicyRulesDocument (Policy.ts:1890-1898) write failure errors to errorFields.rulesDocumentURL and revert the document URL. The Codex review missed that the errors/onClose props are wired — this is a false positive.


3. Wire a download action into workspace document modal (Codex P2)

Verdict: Valid issue — download button is hidden despite the callback being provided.

WorkspaceDocumentModalContent (WorkspaceDocumentModalContent.tsx:40) correctly passes onDownloadAttachment from the useDownloadAttachment hook, but the download button never renders. The shouldShowDownloadButton logic in AttachmentModalBaseContent (index.tsx:190-197) requires either a non-empty report prop or type === ATTACHMENT_TYPE.SEARCH — neither is provided by the workspace document modal, so isValidContext is always false.

The download callback works; it's just unreachable. A fix would be to either pass a prop that satisfies the isValidContext check or adjust the gating logic to also show the button when onDownloadAttachment is provided without a report context.


4. Forward acceptedFileTypes to native picker (abzokhattab)

This is the same underlying issue as #1 above. The acceptedFileTypes prop is defined in the type interface but never destructured or used in index.native.tsx:118-126. The document picker always uses types.allFiles (index.native.tsx:254).

Whether to fix this at the picker level (forwarding acceptedFileTypes to the native document picker) or rely on the existing post-pick validation in the action is a product/UX decision. The post-pick validation prevents bad uploads, but pre-pick filtering would be a better user experience.


Summary:

Issue Valid? Severity
File type validation Partially — server-safe but native UX gap Low
Error display in UI No — already wired correctly N/A
Download button hidden Yes — button never renders Medium
Native acceptedFileTypes Yes — prop is ignored on native Low

Allow workspace admins to upload, replace, and remove a PDF document
on the workspace overview page. Non-admins can view and download it.
PDFs are stored in a private S3 bucket and served through an
authenticated streaming endpoint.
- Rename field: policyDocumentURL → rulesDocumentURL across types,
  actions, utils, and pages
- Rename API commands: UpdatePolicyRulesDocument, DeletePolicyRulesDocument
- Rename param types and files to match
- Rename utility: getPolicyDocumentSourceURL → getRulesDocumentSourceURL
Renamed updateWorkspaceRulesDocument -> updatePolicyRulesDocument and
deleteWorkspaceRulesDocument -> deletePolicyRulesDocument. Updated
GetPolicyDocument -> GetPolicyRulesDocument streaming endpoint.
- Add policyDocument and policyText translation keys to all locales
- Use named constants for thumbnail dimensions instead of magic numbers
- Position three-dots menu on thumbnail with circular background
- Wrap Choose file button to prevent full-width stretch
- Use policyText label for custom rules text field
- Add policyDocument and policyText to es, fr, de, it, ja, nl, pl
- Add sentryLabel to PressableWithoutFeedback for PDF thumbnail
- Add RULES_DOCUMENT sentry label constant
Extract inline style objects for the PDF thumbnail container,
PDFThumbnail, ThreeDotsMenu position, and icon into useMemo
to avoid creating new references on every render.
- Change rulesDocumentThumbnailWidth to rulesDocumentThumbnailMaxWidth for clarity.
- Adjust thumbnail style to use maxWidth and set width to 100% for better responsiveness.
- Update PDFThumbnail component to use a flex style for improved layout.
- Introduce file type validation to ensure only PDF documents are accepted for policy rules.
- Refactor document selection logic to improve readability and maintainability.
- Update UI to handle errors related to invalid file types more effectively.
- Update conditional rendering for the custom rules section to improve clarity and maintainability.
- Adjust subtitle styles based on user permissions and document availability.
- Enhance document handling UI for better user experience, including improved layout and accessibility features.
@ishpaul777 ishpaul777 force-pushed the ishpaul/workspace-rules-document-upload branch from 6dae0b8 to 00b1593 Compare April 22, 2026 14:56
… document

- Show download button in workspace document modal by including onDownloadAttachment in isValidContext check
- Use receiptActionButton style for three-dots menu to match receipt preview icon buttons
- Add shouldCallAfterModalHide to Replace menu item so native picker opens after popover closes
@ishpaul777
Copy link
Copy Markdown
Contributor Author

@abzokhattab @shawnborton

The more button doesn't look correct here:
fixed

Screenshot 2026-04-22 at 9 17 18 PM

On iOS when clicking on replace nothing happens

fixed this

Screen.Recording.2026-04-22.at.9.15.42.PM.mov

also after uploading the PDF and opening it .. it keeps reloading ... is it the same for you?

i can't reproduce this but may be its because your pdf size is large its taking time to download

Screen.Recording.2026-04-22.at.9.00.30.PM.mov

- Map acceptedFileTypes extensions to native picker types (UTIs on iOS, MIME on Android)
- Add shouldSkipAttachmentTypeModal prop to bypass Camera/Gallery/Document modal
- Use shouldSkipAttachmentTypeModal for workspace rules document picker
- Remove all type assertions in favor of String() coercion
@ishpaul777
Copy link
Copy Markdown
Contributor Author

@MelvinBot resolve conflicts

@MelvinBot
Copy link
Copy Markdown
Contributor

⚠️ Something went wrong. This may be a transient issue — try again. If it persists, check status.anthropic.com.

Run details

@ishpaul777
Copy link
Copy Markdown
Contributor Author

@MelvinBot can you try again to fix conflicts

…nflicts

Co-authored-by: Ishpaul Singh <ishpaul777@users.noreply.github.com>
@MelvinBot
Copy link
Copy Markdown
Contributor

Merge conflicts resolved. The only conflict was in src/libs/PolicyUtils.ts — both branches added exports at the end of the exports object (this PR's getRulesDocumentSourceURL and main's getHRConnectionNames/isGustoConnected). Kept all three exports.

Copy link
Copy Markdown
Contributor

@JmillsExpensify JmillsExpensify left a comment

Choose a reason for hiding this comment

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

LGTM. Not going to hold up this PR based on my NAB comment above.

import launchCamera from './launchCamera/launchCamera';
import type AttachmentPickerProps from './types';

const EXTENSION_TO_NATIVE_TYPE: Record<string, string> = {
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.

I think msword and text are not file extensions .. i think we can remove the msword

const EXTENSION_TO_NATIVE_TYPE: Record<string, string> = {
    pdf: String(types.pdf),
    doc: String(types.doc),
    docx: String(types.docx),
    zip: String(types.zip),
    txt: String(types.plainText),
    json: String(types.json),
    xls: String(types.xls),
    xlsx: String(types.xlsx),
    jpg: String(types.images),
    jpeg: String(types.images),
    png: String(types.images),
    gif: String(types.images),
    heif: String(types.images),
    heic: String(types.images),
    tif: String(types.images),
    tiff: String(types.images),
};

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants