Code test for remove camera opt

[ayush-kommunicate]

What do you want to achieve?

• Remove camera option from attachment.

PR Checklist

• I have tested it locally and all functionalities are working fine.
• I have compared it with mocks and all design elements are the same.
• I have tested it in IE Browser.

How was the code tested?

What new thing you came across while writing this code?

In case you fixed a bug then please describe the root cause of it?

Screenshot

NOTE: Make sure you're comparing your branch with the correct base branch

Summary by CodeRabbit

• Bug Fixes
  • Improved file upload functionality for mobile devices with optimized file selection behavior.

[coderabbitai]

Walkthrough

Modified file upload handling in the sidebox component to conditionally apply file restrictions and remove capture attributes based on device type detection on attachment click events.

Changes

Cohort / File(s)	Summary
Handheld File Upload Handling webplugin/js/app/mck-sidebox-1.0.js	Added HANDHELD_FILE_UPLOAD_ACCEPT constant for device-specific file types; conditionally sets or removes accept attribute based on kommunicateCommons.checkIfDeviceIsHandheld() result; removed capture attribute during file picker trigger.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

🚥 Pre-merge checks | ❌ 3

❌ Failed checks (1 warning, 2 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	❓ Inconclusive	The title 'Code test for remove camera opt' is vague and appears to reference testing rather than describing the actual code change, which is removing the camera option from file attachments.	Revise the title to clearly describe the change, such as 'Remove camera capture option from file attachment' or 'Conditionally disable camera capture on handheld devices for file uploads'.
Description check	❓ Inconclusive	The description provides the main objective but lacks critical details; all testing checkboxes are unchecked and testing methodology, design validation, and IE browser compatibility verification are not documented.	Complete the PR checklist by performing local testing and browser validation, document the testing approach, and either check the boxes or explain why they were not completed.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch Remove-camera-option-from-attachment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@webplugin/js/app/mck-sidebox-1.0.js`:
- Around line 13692-13693: The HANDHELD_FILE_UPLOAD_ACCEPT constant is missing
audio formats (.wav and .mp3) so handheld users cannot upload recordings; update
the HANDHELD_FILE_UPLOAD_ACCEPT value to include ".wav" and ".mp3" in the
comma-separated accept string (e.g., append or insert .wav,.mp3 into the
existing string) in the declaration of HANDHELD_FILE_UPLOAD_ACCEPT so
recorder-produced files from webplugin/lib/js/recorder.js can be uploaded.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 7431b09c-93ea-4031-8d82-c60c9bec0a5f

📥 Commits

Reviewing files that changed from the base of the PR and between dcf5289 and e6bf767.

📒 Files selected for processing (1)

• webplugin/js/app/mck-sidebox-1.0.js

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if audio file types are supported elsewhere in the codebase
rg -n --type=js -C3 'audio|\.mp3|\.wav|\.aac|\.ogg|\.flac' --glob '!node_modules/**' | head -50

Repository: Kommunicate-io/Kommunicate-Web-SDK

Length of output: 2915

---

Add audio formats to the handheld file accept list.

The HANDHELD_FILE_UPLOAD_ACCEPT constant is missing .wav and .mp3 formats. The application includes audio recording functionality (webplugin/lib/js/recorder.js) that produces WAV and MP3 files, but handheld users will be unable to upload them due to these missing formats in the accept list.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@webplugin/js/app/mck-sidebox-1.0.js` around lines 13692 - 13693, The
HANDHELD_FILE_UPLOAD_ACCEPT constant is missing audio formats (.wav and .mp3) so
handheld users cannot upload recordings; update the HANDHELD_FILE_UPLOAD_ACCEPT
value to include ".wav" and ".mp3" in the comma-separated accept string (e.g.,
append or insert .wav,.mp3 into the existing string) in the declaration of
HANDHELD_FILE_UPLOAD_ACCEPT so recorder-produced files from
webplugin/lib/js/recorder.js can be uploaded.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e6bf76725d

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

[chatgpt-codex-connector]

Preserve audio uploads in handheld attachment filter

The new handheld accept whitelist blocks selecting audio files because it only includes document/image/video extensions and omits common audio ones like .mp3, .wav, and .m4a. On mobile, this means users opening the generic attachment button cannot choose existing audio files from storage, even though the widget’s message pipeline/rendering supports audio attachments (see the fileType === 'audio' handling later in this file). This changes functional behavior beyond removing camera capture.

Useful? React with 👍 / 👎.