Skip to content

New Instance Scan Check: Identify String Fields with Excessive Max Length #143

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 16, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -168,6 +168,9 @@ The Choice table should not be used as the reference table for a Reference type

## Category: Performance

### Identifies string fields with max_length exceeding recommended limits
This scan checks for string fields where the max_length value is set above a recommended limit. Setting a very high max_length can result in unnecessary database storage consumption and may degrade query performance. It is important to use reasonable max_length values based on actual data requirements.

### getMessage() called in Client Script
This is a simple table check to find client scripts with use the getMessage function but do not preload messages using the Messages field. As the check does a simple contains query it could produce false-positives if the getMessage is either commented or from another library.

Expand Down
18 changes: 18 additions & 0 deletions ca8467c41b9abc10ce0f62c3b24bcbaa/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# Generated files
This repository contains generated files and a checksum.

If you find yourself unable to import your repository due to the presence of files edited outside an instance of ServiceNow, merge commits that mix files from different revisions, or other data that does not match the checksum, you may recover using either of the following techniques:
* Remove the problem commits:
1. Clone your repository to a personal computer with the git command line tools installed and open a git command prompt in the repository root
2. Run `git log` and take note of the SHA1s of the problem commits
3. Build revert commits using `git revert SHA1` repeatedly, working backward in time, for each commit that introduced changes not generated by a ServiceNow instance
4. Run `git push`

* Overwrite the problem code snapshot with a known good one:
1. Clone your repository to a personal computer with the git command line tools installed and open a git command prompt in the repository root,
2. Locate a known good code snapshot and record its SHA1. For this step, `git log` can be useful.
2. Run `git reset --hard SHA1` to a commit that was generated by a ServiceNow instance
3. Run `git reset HEAD{1}`
4. Run `git add -A`
5. Run `git commit`
6. Run `git push`
2 changes: 1 addition & 1 deletion ca8467c41b9abc10ce0f62c3b24bcbaa/checksum.txt
Original file line number Diff line number Diff line change
@@ -1 +1 @@
WWQm_IdWsTxg4URwBle2eXw7sIYuz7QcfROoa5TolyTIo-4kY4yJv9mdj4AV6pxGDqmcce-OqWYk2SRfmXXkpFqgbPUkM2EpKlebMDOKFW2seNgYWN4bkeJ9_Q6L0iEK6I6CR2QT3cGXnUdGOTJcKtOLprLFRIuuxIyn5oIOPoM6Kt1ok5D6usEHVLLSIVKw_2ipwP0u2uEaw_Gik4mla7e-vqKVXeArvB3AyUf6w1x-mRUIYg2ovffLI4ZvhIhdXuo8RFxkzAc5KvSWwMydfQ7Bqnvxc_ZPwwISUEJUshlpVExoEXU4N4ht15P5IrELTHQUYN6qlonJWzWP_kmjEZKO9zpr6yav5-Swp7Rtati5ByQx8sfdfX-MNa1Fg8eAPZUXTQiCiVMIonfzrgDZdUfRWi8kZfN0DnVxS0Drb31u3uroGnsrg4aa5QDU6upUoaX_sUGAdZfoRDxQwU42PA0qu8WKDAwaxdNgsSOy6hFn0rF3BCQkU1aI4aBsx_9P2o58Tp44Xe6IDNO_PuVGIfivJs7DVZzKbHdk4fdc8zRmv2Wl9nwbPpTEKHBDHalqO27RbZGOsB-vUswKKjlEYfgWT5aXoppZaaMI5zvdOvzyE1NsBDSahgAgQBuLSMrK8ZtGILILJn-6gGmh5dZHKbVEzDwrq_H41tkVvlfcJc
vdzK57T2bhYH4R3tr5_N6r8DKdLmhtc5_AMSqsrGL2lDDQtzZxnmirx38up8Jm2-CI3CDMpa7Udq0cV06a0WfIeCBFsws8y-joYHTxiD-lAbbpy7LKyBy-szR_kO4mFszdz7Kikp9bbMUwWTIPbtRQzbapfu6HH7iEFepuUdA9SOlwPJAAaBRxCUQeo8Hg9Hxb7ubHmvx87l7IwoGN2ezq07g2EMDh3wkpLdXVXdMoPd-Hf9g8X-V4ENLaGI-5wQnvXgX_w_shWoupz_WdTA3ir94Eh3Nu2jiM29wNQDNrlsTvslryId4vq8M8ME13Vi7UpuHw6Ec-ooT6OXdBMkvgsVAtCARdy79UbAgT_p9E3KL3rbJPozp-7I8wOf3n1WETwJkDsAUMzBp3LWF8_BqfxFeYFCEQV3l3xC8ic2ZQn_98i9fpgURFU9Ec2BEGbbMfpm7KehrFl0bNOVDTDEWIETdt80lvfR1i0-8Yk1vHWvLdB94dHoPw1a77oWht1HxEMkNzE1m38ANVQVZq2-pbVdIiAYCLeRBdd5i_LrNLpF7iCHBpAawuxX5BQIVKBW3WNTPhWUdV9_a1_394CDBmYswn8XiQSx0Vi0hfjuuMp9J9sQxOVVq2MFyWZiDvhIX2CJutq8xn27shQc7Y5xeZN5SVosFrv3irWYkzJuKoU
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
<?xml version="1.0" encoding="UTF-8"?><record_update table="scan_table_check">
<scan_table_check action="INSERT_OR_UPDATE">
<active>true</active>
<advanced>false</advanced>
<category>performance</category>
<conditions table="sys_dictionary">internal_type=string^ORinternal_type=string_full_utf8^max_length&gt;4000^nameNOT LIKEsys_hub^EQ<item display_table="sys_glide_object" display_value="String" endquery="false" field="internal_type" goto="false" newquery="false" operator="=" or="false" value="string"/>
<item endquery="false" field="internal_type" goto="false" newquery="false" operator="=" or="true" value="string_full_utf8"/>
<item endquery="false" field="max_length" goto="false" newquery="false" operator="&gt;" or="false" value="4000"/>
<item endquery="false" field="name" goto="false" newquery="false" operator="NOT LIKE" or="false" value="sys_hub"/>
<item endquery="true" field="" goto="false" newquery="false" operator="=" or="false" value=""/>
</conditions>
<description>This scan checks for string fields where the max_length value is set above a recommended limit. Setting a very high max_length can result in unnecessary database storage consumption and may degrade query performance. It is important to use reasonable max_length values based on actual data requirements.</description>
<documentation_url>https://support.servicenow.com/kb?id=kb_article_view&amp;sysparm_article=KB0685779</documentation_url>
<finding_type>scan_finding</finding_type>
<name>String Fields with Excessive Max Length</name>
<priority>3</priority>
<resolution_details>Review the identified string fields and adjust the max_length to a value that matches the actual data requirements.&#13;
&#13;
Use lower values for fields that only need to store short text. For fields that may contain longer content, consider using appropriate max_length values, such as 255 for typical text fields. &#13;
&#13;
Avoid setting max_length values unnecessarily high to reduce the impact on storage and performance.</resolution_details>
<run_condition/>
<score_max>100</score_max>
<score_min>0</score_min>
<score_scale>1</score_scale>
<script><![CDATA[(function(finding) {

})(finding);
]]></script>
<short_description>Identifies string fields with max_length exceeding recommended limits</short_description>
<sys_class_name>scan_table_check</sys_class_name>
<sys_created_by>admin</sys_created_by>
<sys_created_on>2024-10-15 21:43:15</sys_created_on>
<sys_id>8b90df49839112107b681390ceaad3be</sys_id>
<sys_mod_count>6</sys_mod_count>
<sys_name>String Fields with Excessive Max Length</sys_name>
<sys_package display_value="Example Instance Checks" source="x_appe_exa_checks">ca8467c41b9abc10ce0f62c3b24bcbaa</sys_package>
<sys_policy/>
<sys_scope display_value="Example Instance Checks">ca8467c41b9abc10ce0f62c3b24bcbaa</sys_scope>
<sys_update_name>scan_table_check_8b90df49839112107b681390ceaad3be</sys_update_name>
<sys_updated_by>admin</sys_updated_by>
<sys_updated_on>2024-10-15 22:11:06</sys_updated_on>
<table>sys_dictionary</table>
<use_manifest>false</use_manifest>
</scan_table_check>
<sys_translated_text action="delete_multiple" query="documentkey=8b90df49839112107b681390ceaad3be"/>
</record_update>
Loading