servicenowdevprogram / example-instancescan-checks Goto Github PK

Sometimes, when developing new Catalog Items/Record Producers, I find left over Catalog UI Policies that are not used anywhere - not associated with a catalog item and also not associated with a variable set. These are unnecessary configurations that just create bloat in your system and it is likely best to not move these configurations to production.

An Instance Scan could flag them/find them so that you can remove them from your Update Set and clean them up.

Full example at: https://www.servicenow.com/community/developer-articles/instance-scan-orphaned-catalog-configurations-examples/ta-p/2302050

Improve the Script Only Check named "Update set should not have more than 1000 updates".

• It should exclude default update sets.
• It doesn't currently identify the matching update set correctly in the results, just that that there is a matching update set to this check.

See https://docs.servicenow.com/bundle/tokyo-platform-administration/page/administer/technical-best-practice/concept/c_TroubleshootImportSetPerformance.html

I think the repo is hitting a tipping point where it's hard to see, browse, and maintain the list of checks in the repos README.

Would enabling the wiki be better from a usability perspective so you can have hierarchy for the categories and automatically alphabetized lists? 🤷‍♀️

The glide.invalid_query.returns_no_rows prevents invalid queries from returning rows and would be a good practice to have in place. See: https://www.servicenow.com/community/developer-blog/protect-custom-scripts-from-unwanted-behavior-using-this-system/ba-p/2291471

Sometimes when developing new Catalog Items, I find left over client scripts that are not used anywhere - not associated with a catalog item and also not associated with a variable set. These are unnecessary configurations that just create bloat in your system and it is likely best to not move these configurations to production.

An Instance Scan could flag them/find them so that you can remove them from your Update Set and clean them up.

See example at: https://www.servicenow.com/community/developer-articles/instance-scan-orphaned-catalog-configurations-examples/ta-p/2302050

When using setValue() on a reference field, be sure to include the display value with the value (sys_id). If you set the value without the display value, ServiceNow does a synchronous Ajax call to retrieve the display value for the record you specified. This extra round trip to the server can leave you at risk of performance issues.

More at https://developer.servicenow.com/dev.do#!/guides/tokyo/now-platform/tpb-guide/client_scripting_technical_best_practices

Three duplicates were found in the repo:

Sometimes when developing new Catalog Items, I find left over variables that are not used anywhere - not associated with a catalog item and also not associated with a variable set. These are unnecessary configuration that just create bloat in your system and it is likely best to not move these configurations to production.

An Instance Scan could flag them/find them so that you can remove them from your Update Set and clean them up.

Full example at: https://www.servicenow.com/community/developer-articles/instance-scan-orphaned-catalog-configurations-examples/ta-p/2302050

See https://sn-nerd.com/2023/09/05/why-you-should-stop-using-alert-in-your-client-scripts-now/

Similar to other hacktoberfest repositories, we should be consistent and have a banner at the top of each repo's readme.md file.
The file should be in a 4:1 aspect ratio. (eg. 1600px wide and 400 pixels height).

Show an error/warning when a console.log, gs.log, gs.print, is left.

Create new Linter Check type Instance Scan for use of GlideRecord Secure on Client Callable Script Includes

As per https://docs.servicenow.com/bundle/utah-api-reference/page/script/server-scripting/concept/c_ScriptIncludes.html#title_client-callable-script-includes

Note: there is already an existing Table Check for this. This issue is for a Linter type check.

App scoping issue - warning in the logs:

java.lang.SecurityException: Method returned an object of type GlideRecord which is not allowed in scope x_appe_exa_checks
Caused by error in Linter Check: 'Linter check name here' at Line 4

The Readme file was updated incorrectly at some point. The heading and the description do not match. Heading should be fixed to match the description of the check. See the headings just above this one for similar check description.

Update set description should not be empty

Catalog UI policy should be used in either a Catalog Item or a Variable Set. Catalog UI Policies not in use should be deleted.

It seems possible to create a Script Include with an invalid name (eg. one with a space in the name) . Initially, the Script checker will complain about Javascript errors:

But it's possible to fix those errors, forget to fix the script name, and then save the record:

As per https://docs.servicenow.com/bundle/utah-api-reference/page/script/server-scripting/concept/c_ScriptIncludes.html#title_client-callable-script-includes

getReference is considered against best practice since it can impact performance. See: https://docs.servicenow.com/bundle/vancouver-api-reference/page/script/client-scripts/concept/client-script-best-practices.html

Copied from link:
Note: GlideRecord and g_form.getReference() are also available for retrieving server information. However, these methods are no longer recommended due to their performance impact. Both methods retrieve all fields in the requested GlideRecord when most cases only require one field.

As per https://docs.servicenow.com/bundle/utah-platform-security/page/administer/contextual-security/task/t_CreateAnACLRule.html: