#2579 UI fixes for Auto Approve

[Mnehmos]

#2579 UI fixes for Auto Approve

Context

This PR introduces a new setting for auto-approving API request limits and refines the visual behavior of auto-approve toggles based on the overall auto-approval state.

Scope

• Modified webview-ui/src/components/settings/AutoApproveToggle.tsx to visually indicate when individual auto-approve actions are disabled due to the overall auto-approval being turned off.

Expected Output

• The auto-approve action toggles will appear visually disabled (with reduced opacity) when the main "Auto-Approve" checkbox is unchecked, even if their individual settings are true.

Related GitHub Issue

Closes: #

Description

AutoApproveToggle.tsx component has been updated to provide clearer visual feedback. When the main "Auto-Approve" checkbox is unchecked, individual auto-approve action toggles will now appear with reduced opacity, indicating that they are effectively disabled, regardless of their individual true or false state. This improves the user experience by making the overall auto-approval state more intuitive.

Test Procedure

Test Auto-Approve Toggle Visuals:
* Open the Auto-Approve menu.
* Ensure some individual auto-approve actions (e.g., "Read-Only", "Write") are enabled (their buttons are in the "default" variant).
* Uncheck the main "Auto-Approve" checkbox at the top of the menu.
* Observe that all individual auto-approve action buttons (e.g., "Read-Only", "Write", "Execute") now appear with reduced opacity, even if their individual settings are still true.
* Check the main "Auto-Approve" checkbox again.
* Verify that the individual auto-approve action buttons return to their normal visual state (full opacity, reflecting their individual true/false settings).
* Ensure that Auto-Approve checkbox is not interactive when no action buttons are selected for auto approval

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• [x ] Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• [x ] Self-Review: I have performed a thorough self-review of my code.
• [x ] Code Quality:
  • [x ] My code adheres to the project's style guidelines.
  • [x ] There are no new linting errors or warnings (npm run lint).
  • [x ] All debug code (e.g., console.log) has been removed.
• [x ] Testing:
  • [x ] New and/or updated tests have been added to cover my changes.
  • [x ] All tests pass locally (npm test).
  • [x ] The application builds successfully with my changes.
• [x ] Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• [x ] Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Documentation Updates

• No documentation updates are required.
• Yes, documentation updates are required. (The docs/settings.md file should be updated to include the new "Auto-approve API request count limit" setting.)

Additional Notes

Greatly simplfied scope

Get in Touch