Content
View differences
Updated by Yan Zubrytskyi 3 days ago
**As a** mobile app user
**I want to** scan documents or capture text into the text editor from my camera, photo gallery, or files
**so that** I can quickly add accurate content without manual typing.
### Acceptance Criteria
* Add a new action entry `Scan to text` inside the text editor toolbar’s `More (⋯)` menu.
* Tapping “Scan” opens a bottom sheet with three options:
* Scan with camera
* Import from photo gallery
* Import from files
* If the OS provides a native document scanning UI (e.g., iOS VisionKit document camera), use it as the default “Scan with Camera” experience. _\[TBD\]_
* If native document scan UI is not available on the platform/OS version, hide the scan option from the menu.
* `Import from photo gallery` allows selecting only one image, then process it.
* `Import from files` allows selecting one supported file (at minimum: PDF and common image types), then proceeds to processing.
* After processing, show a preview screen before insertion with:
* The detected content text is added to the text editor box (eg. description or comments)
* OCR output insertion rules:
* Insert at the current cursor position if cursor is active
* Otherwise append to the end of the editor content
* Preserve existing editor content that was filled before and add the text below the cursor position
* If the user has selected text, the default behavior is to replace the selected text with the scanned text
* If OCR returns no text (e.g., blank image), show a clear empty-state message "No text detected, please try again".
* The feature must request camera permission only when the user selects `Scan with camera` and if they didn't give previous permissions.
* If camera permission is denied:
* Show a message "Camera permission denied. Please, give permissions on the device settings"
* If photo gallery access is restricted/denied:
* Show a message "Photo gallery access denied. Please, give permissions on the device settings"
* Processing must show progress and remain responsive:
* Display a spinner/progress state during OCR and file conversion
* Supported input types and constraints must be enforced:
* Large files/images that exceed configured limits show an error with guidance with a message "File is too big, please try a smaller file"
* Unsupported file types show an error and do not insert anything. The error should say "This file type is not supported"
* In case if current app language is one of this: _Devengari, Japanase, Koeran, Chinese, Arabic, Hebrew, Farsi, Central Kurdish, Thai, Geordian, Greek, Sinhala, Russian, Ukranian, Bulgarian, Belarusian, Kazakh, Mongolian, and Cyrillic Serbian_; user will see an [inform dialog](https://www.figma.com/design/xiZOMN9Vdgm5RiZotIRa7p/Mobile-app---Work-packages-module?node-id=2244-990) about limitations
### Technical Notes
* _**TO BE CHECKED BY DEVELOPMENT**_
* Platform capabilities (recommended approach):
* iOS:
* Document scanning UI: VisionKit Document Camera (native scan UX, edge detection, multi-page).
* OCR: Apple Vision framework (on-device text recognition) for images/pages.
* Android:
* Document scanning UI: likely requires a library or Google-provided scanning component (availability varies). If no stable native scanner UI exists for all target devices, implement capture + processing in-app.
* OCR: ML Kit Text Recognition (on-device) is a common approach; may be dependency-based.
* Library vs OS decision:
* Prefer OS-native scanning UI when it exists and is stable across the target OS range.
* Use a shared OCR layer that can accept:
* Camera-captured images
* Photo gallery images
* Extracted pages/images from PDFs
### Permissions and Visibility Considerations
* Camera scanning is available only to users whose device supports camera access; if no camera is present, hide “Scan with camera”.
* If the app has role-based restrictions for attachments or rich content:
* Users without attachment permission can still insert recognized text
* Respect OS permissions:
* Denied permissions should degrade gracefully without blocking other source options
### Translation Considerations
* Localize UI strings:
* “Scan to text”
* “Scan with camera”
* “Import from photo gallery”
* “Import from files”
* Permission explanations and error messages
* Must NOT be translated:
* File extensions (PDF, JPG, PNG)
* Internal error codes / diagnostic IDs (if shown)
### Out of Scope
* Advanced document editing (cropping, rotation, perspective correction UI) beyond what the OS scanner provides (unless required for non-native fallback).
* Structured data extraction (tables, forms, receipts parsing) beyond plain OCR text.
* Automatic language translation of scanned text.
* Handwriting recognition guarantees (may work opportunistically but not required).
* Full document management (naming, storing, searching scanned documents) outside inserting into the current editor.
* Synchronization/sharing workflows for scanned files beyond existing attachment handling.
**I want to** scan documents or capture text into the text editor from my camera, photo gallery, or files
**so that** I can quickly add accurate content without manual typing.
### Acceptance Criteria
* Add a new action entry `Scan to text` inside the text editor toolbar’s `More (⋯)` menu.
* Tapping “Scan” opens a bottom sheet with three options:
* Scan with camera
* Import from photo gallery
* Import from files
* If the OS provides a native document scanning UI (e.g., iOS VisionKit document camera), use it as the default “Scan with Camera” experience. _\[TBD\]_
* If native document scan UI is not available on the platform/OS version, hide the scan option from the menu.
* `Import from photo gallery` allows selecting only one image, then process it.
* `Import from files` allows selecting one supported file (at minimum: PDF and common image types), then proceeds to processing.
* After processing, show a preview screen before insertion with:
* The detected content text is added to the text editor box (eg. description or comments)
* OCR output insertion rules:
* Insert at the current cursor position if cursor is active
* Otherwise append to the end of the editor content
* Preserve existing editor content that was filled before and add the text below the cursor position
* If the user has selected text, the default behavior is to replace the selected text with the scanned text
* If OCR returns no text (e.g., blank image), show a clear empty-state message "No text detected, please try again".
* The feature must request camera permission only when the user selects `Scan with camera` and if they didn't give previous permissions.
* If camera permission is denied:
* Show a message "Camera permission denied. Please, give permissions on the device settings"
* If photo gallery access is restricted/denied:
* Show a message "Photo gallery access denied. Please, give permissions on the device settings"
* Processing must show progress and remain responsive:
* Display a spinner/progress state during OCR and file conversion
* Supported input types and constraints must be enforced:
* Large files/images that exceed configured limits show an error with guidance with a message "File is too big, please try a smaller file"
* Unsupported file types show an error and do not insert anything. The error should say "This file type is not supported"
* In case if current app language is one of this: _Devengari, Japanase, Koeran, Chinese, Arabic, Hebrew, Farsi, Central Kurdish, Thai, Geordian, Greek, Sinhala, Russian, Ukranian, Bulgarian, Belarusian, Kazakh, Mongolian, and Cyrillic Serbian_; user will see an [inform dialog](https://www.figma.com/design/xiZOMN9Vdgm5RiZotIRa7p/Mobile-app---Work-packages-module?node-id=2244-990) about limitations
* _**TO BE CHECKED BY DEVELOPMENT**_
* Platform capabilities (recommended approach):
* iOS:
* Document scanning UI: VisionKit Document Camera (native scan UX, edge detection, multi-page).
* OCR: Apple Vision framework (on-device text recognition) for images/pages.
* Android:
* Document scanning UI: likely requires a library or Google-provided scanning component (availability varies). If no stable native scanner UI exists for all target devices, implement capture + processing in-app.
* OCR: ML Kit Text Recognition (on-device) is a common approach; may be dependency-based.
* Library vs OS decision:
* Prefer OS-native scanning UI when it exists and is stable across the target OS range.
* Use a shared OCR layer that can accept:
* Camera-captured images
* Photo gallery images
* Extracted pages/images from PDFs
### Permissions and Visibility Considerations
* Camera scanning is available only to users whose device supports camera access; if no camera is present, hide “Scan with camera”.
* If the app has role-based restrictions for attachments or rich content:
* Users without attachment permission can still insert recognized text
* Respect OS permissions:
* Denied permissions should degrade gracefully without blocking other source options
### Translation Considerations
* Localize UI strings:
* “Scan to text”
* “Scan with camera”
* “Import from photo gallery”
* “Import from files”
* Permission explanations and error messages
* Must NOT be translated:
* File extensions (PDF, JPG, PNG)
* Internal error codes / diagnostic IDs (if shown)
### Out of Scope
* Advanced document editing (cropping, rotation, perspective correction UI) beyond what the OS scanner provides (unless required for non-native fallback).
* Structured data extraction (tables, forms, receipts parsing) beyond plain OCR text.
* Automatic language translation of scanned text.
* Handwriting recognition guarantees (may work opportunistically but not required).
* Full document management (naming, storing, searching scanned documents) outside inserting into the current editor.
* Synchronization/sharing workflows for scanned files beyond existing attachment handling.