Prevent Rejection Without Comments

[Suri123789]

PR Description:

Adds a Client Script on the sysapproval_approver table to ensure that approvers must provide comments before rejecting an approval record. Improves audit transparency and process integrity.

Pull Request Checklist

Overview

• Put an x inside of the square brackets to check each item.
• I have read and understood the CONTRIBUTING.md guidelines
• My pull request has a descriptive title that accurately reflects the changes and the description has been filled in above.
• I've included only files relevant to the changes described in the PR title and description
• I've created a new branch in my forked repository for this contribution

Code Quality

• My code is relevant to ServiceNow developers
• My code snippets expand meaningfully on official ServiceNow documentation (if applicable)
• I've disclosed use of ES2021 features (if applicable)
• I've tested my code snippets in a ServiceNow environment (where possible)

Repository Structure Compliance

• I've placed my code snippet(s) in one of the required top-level categories:
  • Core ServiceNow APIs/
  • Server-Side Components/
  • Client-Side Components/
  • Modern Development/
  • Integration/
  • Specialized Areas/
• I've used appropriate sub-categories within the top-level categories
• Each code snippet has its own folder with a descriptive name

Documentation

• I've included a README.md file for each code snippet
• The README.md includes:
  • Description of the code snippet functionality
  • Usage instructions or examples
  • Any prerequisites or dependencies
  • (Optional) Screenshots or diagrams if helpful

Restrictions

• My PR does not include XML exports of ServiceNow records
• My PR does not contain sensitive information (passwords, API keys, tokens)
• My PR does not include changes that fall outside the described scope

[am-shakeel]

Thanks for submitting this! Since it’s a low-effort PR for Hacktoberfest, that’s totally fine
Just a quick note: this repo already has similar examples, so it might be worth checking for duplicates before submitting. That said, the use case does make sense in certain scenarios, so I’m accepting it as a valid contribution. If you plan to extend this (e.g., support Change Request validations or make it reusable across tables) happy to collaborate!