From 6a61498ca559efd0dc734239f712b207040e8c13 Mon Sep 17 00:00:00 2001 From: krishna-medapati Date: Tue, 11 Nov 2025 14:26:13 +0530 Subject: [PATCH] fix: standardize README filename casing to prevent collisions on case-insensitive filesystems --- .../Auto-Populate Short Discription/Readme.md | 36 ------- .../validate phone number/Readme.md | 39 ------- .../Readme.md | 100 ------------------ .../CMDB/CMDB Utility Scripts/ReadME.md | 18 ---- .../updateMultipleRecords/readme.md | 15 --- .../ITOM/Track Discovery Status/readme.md | 43 -------- 6 files changed, 251 deletions(-) delete mode 100644 Client-Side Components/Client Scripts/Auto-Populate Short Discription/Readme.md delete mode 100644 Client-Side Components/Client Scripts/validate phone number/Readme.md delete mode 100644 Server-Side Components/Background Scripts/Convert Incident Records to JSON/Readme.md delete mode 100644 Specialized Areas/CMDB/CMDB Utility Scripts/ReadME.md delete mode 100644 Specialized Areas/Fix scripts/updateMultipleRecords/readme.md delete mode 100644 Specialized Areas/ITOM/Track Discovery Status/readme.md diff --git a/Client-Side Components/Client Scripts/Auto-Populate Short Discription/Readme.md b/Client-Side Components/Client Scripts/Auto-Populate Short Discription/Readme.md deleted file mode 100644 index 4dab2bdbd8..0000000000 --- a/Client-Side Components/Client Scripts/Auto-Populate Short Discription/Readme.md +++ /dev/null @@ -1,36 +0,0 @@ -# Auto-Populate Short Description (Client Script) -## Overview - -This client script automatically updates the Short Description field in ServiceNow whenever a user selects a category on the form. It improves data consistency, saves time, and ensures that short descriptions remain meaningful and standardized. - -## How It Works - -When a user selects a category such as Hardware, Software, or Network, the script automatically prefixes the existing short description with a corresponding label (for example, “Hardware Issue –”). -This makes incident records easier to identify and improves the quality of data entry. - -## Configuration Steps - -1. Log in to your ServiceNow instance with admin or developer access. -2. Navigate to System Definition → Client Scripts. -3. Create a new Client Script with the following details: - -``` -Table: Incident -Type: onChange -Field name: category -Copy and paste the provided script into the Script field. -Save the record and make sure the script is active. -``` - -## Testing - -1. Open any existing or new Incident record. -2. Select a category such as Hardware or Software. -3. The Short Description field will automatically update with the corresponding prefix. - -## Benefits - -Speeds up data entry for users. -Maintains consistency in short descriptions. -Reduces manual effort and human errors. -Enhances clarity in incident listings and reports. diff --git a/Client-Side Components/Client Scripts/validate phone number/Readme.md b/Client-Side Components/Client Scripts/validate phone number/Readme.md deleted file mode 100644 index 5f47923199..0000000000 --- a/Client-Side Components/Client Scripts/validate phone number/Readme.md +++ /dev/null @@ -1,39 +0,0 @@ -Phone Number Validation — Client Script -Overview - -This Client Script validates that users enter their phone numbers in the strict format: (123) 456-7890. - -It is triggered whenever the Phone field changes on a sys_user record. If the input does not match the required format, the script: - -Displays an inline error message directly below the field. - -Clears the invalid input so the user can re-enter the correct value. - -This script is designed to be dynamic, simple, and user-friendly. - -Features - -Ensures phone numbers follow the exact format (123) 456-7890. - -Provides immediate feedback via field-level error messages. - -Clears invalid entries automatically to prevent submission errors. - -Works on Classic UI forms and provides clear messaging to the user. - -Usage Instructions -1. Create the Client Script - -Navigate to System Definition → Client Scripts. - -Click New to create a client script. - -2. Configure the Script - -Name: Phone Number Validation - -Table: sys_user - -Type: onChange - -Field: phone diff --git a/Server-Side Components/Background Scripts/Convert Incident Records to JSON/Readme.md b/Server-Side Components/Background Scripts/Convert Incident Records to JSON/Readme.md deleted file mode 100644 index 565466e9ba..0000000000 --- a/Server-Side Components/Background Scripts/Convert Incident Records to JSON/Readme.md +++ /dev/null @@ -1,100 +0,0 @@ -# Active Incidents JSON Export – ServiceNow - -This repository contains **two approaches** to fetch active incidents from ServiceNow and convert them to JSON. Both use `GlideRecord` but differ in flexibility and readability. - ---- - -## 1. Simple Approach - -This method fetches a **fixed set of fields** and converts them directly to JSON. - -```javascript -var incidents = []; -var gr = new GlideRecord('incident'); -gr.addQuery('active', true); -gr.query(); -while (gr.next()) { - incidents.push({ - number: gr.number.toString(), - short_description: gr.short_description.toString(), - state: gr.state.toString(), - assigned_to: gr.assigned_to.getDisplayValue('name'), - created_on: gr.sys_created_on.getDisplayValue() - }); -} - -var jsonOutput = JSON.stringify(incidents); -gs.info(jsonOutput); -``` - -### ✅ Pros -- Simple and easy to implement -- Works fine for a fixed set of fields -- Direct JSON output - -### ❌ Cons -- Fields are hard-coded → not reusable for other tables -- Reference fields handling is not dynamic -- Numeric state values are not human-readable - ---- - -## 2. Flexible & Dynamic Approach - -This method allows dynamic fields, handles reference fields, and adds human-readable state labels. - -```javascript -var tableName = 'incident'; -var fieldsToInclude = ['number', 'short_description', 'state', 'assigned_to', 'sys_created_on']; -var incidentList = []; - -var gr = new GlideRecord(tableName); -gr.addQuery('active', true); -gr.query(); - -while (gr.next()) { - var incidentObj = {}; - - fieldsToInclude.forEach(function(field) { - if (gr.isValidField(field) && gr[field].getRefRecord) { - incidentObj[field] = gr[field].getDisplayValue(); - } else if (gr.isValidField(field)) { - incidentObj[field] = gr[field].toString(); - } else { - incidentObj[field] = null; - } - }); - - // Map numeric state to human-readable label - var stateMap = { - '1': 'New', - '2': 'In Progress', - '3': 'On Hold', - '6': 'Resolved', - '7': 'Closed' - }; - incidentObj.state_label = stateMap[incidentObj.state] || 'Unknown'; - - incidentList.push(incidentObj); -} - -var jsonOutput = JSON.stringify(incidentList, null, 2); -gs.info("Here's your JSON for active incidents:\n" + jsonOutput); -``` - -### ✅ Pros -- Dynamic → easily reusable for any table and fields -- Handles reference fields gracefully -- Adds human-readable state labels -- JSON is formatted for readability -- Checks `isValidField` to prevent errors - -### ❌ Cons -- Slightly more complex than the simple version -- Requires manual mapping for fields like state labels - - -## Summary - -- **Simple Approach**: Best for quick tasks with fixed fields -- **Flexible Approach**: Best for reusable scripts, handling dynamic tables, reference fields, and human-readable output \ No newline at end of file diff --git a/Specialized Areas/CMDB/CMDB Utility Scripts/ReadME.md b/Specialized Areas/CMDB/CMDB Utility Scripts/ReadME.md deleted file mode 100644 index 072ea0e347..0000000000 --- a/Specialized Areas/CMDB/CMDB Utility Scripts/ReadME.md +++ /dev/null @@ -1,18 +0,0 @@ -This script is used in ServiceNow to automatically fill in the missing manufacturer information for Configuration Items (CIs) in the CMDB (Configuration Management Database). - -1. Predefined Mapping: -The script starts with a list of known model names and their corresponding manufacturer names.For example, a model called ThinkPad T14 is made by Lenovo, and MacBook Pro 16 is made by Apple -2. Look Up Manufacturer: - * It defines a function that looks up the manufacturer’s record in the core_company table (based on the name) and gets its unique ID (sys_id). -3. Find CIs Missing a Manufacturer: - * The script goes through all CIs in the cmdb_ci table where the manufacturer field is empty. -4. Update Missing Manufacturer: - * For each of those CIs: - * It checks the model name. - * If the model is in the predefined mapping: - * It looks up the correct manufacturer in the core_company table. - * It updates the CI record by setting the manufacturer field with the correct sys_id. - * It also logs that the update was successful. - * If the manufacturer is not found in the system, it logs a warning. -5. Final Log: - * After going through all matching CIs, it logs how many records were successfully updated. diff --git a/Specialized Areas/Fix scripts/updateMultipleRecords/readme.md b/Specialized Areas/Fix scripts/updateMultipleRecords/readme.md deleted file mode 100644 index 3d914a4e98..0000000000 --- a/Specialized Areas/Fix scripts/updateMultipleRecords/readme.md +++ /dev/null @@ -1,15 +0,0 @@ -## update Multiple Records -These 2 scripts are used to update Multiple records but in different ways -### update_multiple_records.script file -In this script it uses `updateMultiple()` Function -1. In this script it uses `updateMultiple()` Function -2. Automatically updates system fields like sys_updated_by and sys_updated_on. -3. Cannot skip system fields using autoSysFields(false). -4. Always triggers workflows, business rules, and script actions. -5. Cannot disable per record. - -### update_multiple_records_v2.script file -In this script it uses `update()` Function -1. update() is a GlideRecord method used to update a single record in the database. It is commonly used inside a loop to update multiple records individually. -2. Can skip updating system fields using autoSysFields(false). -3. Can skip workflows/business rules using setWorkflow(false). \ No newline at end of file diff --git a/Specialized Areas/ITOM/Track Discovery Status/readme.md b/Specialized Areas/ITOM/Track Discovery Status/readme.md deleted file mode 100644 index ff8b97ca91..0000000000 --- a/Specialized Areas/ITOM/Track Discovery Status/readme.md +++ /dev/null @@ -1,43 +0,0 @@ -After a recent migration, the client wanted a quick and reliable way to verify whether specific IP addresses were being discovered by ServiceNow Discovery, and if so, determine which Discovery Status records they were associated with. - -This requirement was critical to help the client: - -Identify IPs that were discovered successfully. - -Find those that were not rediscovered after migration. - -Diagnose potential discovery or configuration issues efficiently. - -The script provided below serves as a powerful troubleshooting utility. It allows administrators to instantly check which discovery job (status) a given IP address belongs to, enabling faster debugging and drastically reducing resolution time. - -What the Script Does - -The script performs the following steps: - -Takes a list of IP addresses as input. - -Looks up each IP in the cmdb_ci_computer table(It could be Linux, AIX,etc.) to find its corresponding Configuration Item (CI). - -Queries the Discovery Device History (discovery_device_history) to determine whether the CI was created or updated by a discovery process. - -Builds a JSON array mapping each IP address to its respective discovery status number (e.g., DIS123145). - -Prints the result in the system logs for quick review and validation. - -Example output: - -[ - {"ip_address": "192.168.1.35", "discovery_status_number": "DIS123145"}, - {"ip_address": "192.168.1.27", "discovery_status_number": "DIS123189"}, - {"ip_address": "192.168.1.15", "discovery_status_number": "No discovery record found"} -] - -Benefits - -Saves significant debugging and analysis time. - -Helps identify why certain CIs stopped being discovered after migration. - -Provides clear mapping between IP addresses and their last discovery statuses. - -Enables faster root cause analysis and improves operational efficiency.