Get-ServiceNowAttachment does not work on not known tables

[mdehaas]

Environment

Windows Server based hosting for workplace and application (backends)

Operating System: Windows Server 2012 R2 Standard ServiceNow module version: 3.1.11 PowerShell version: 7.2.1 Core

Steps to reproduce

We try to eneumerate the attachments of a Knowledgebase (table: kb_knowledgebase) article or a ToDo (table: ticket). This present no results even though there are attachments in the record. Getting attachments for known types works as expected.

Get-ServiceNowAttachment -Id 'KB0012334' -Table 'kb_knowledge' Get-ServiceNowAttachment -Id 'TDO0018239' -Table 'ticket' -Verbose

We can however upload files to these record types which reflects in the webinterface of Servicenow. So probably permissions are not the issue. I'm working on this issue with @wilcodl

Expected behavior

A returned Powershell object with the names and metadata of the files

Actual behavior

Verbose output shows there are no records for attachments.

VERBOSE: Total number of records for this query: 0

The thing I am not certain about is when creating the Servicenow session: New-ServiceNowSession -Url "$($cfgServicenowUrl)" -Credential ($Passwords | Where {$_.Type -eq "Servicenow"}).Credential -GetAllTable -Verbose

I get this in the verbose output:

VERBOSE: Session created, but failed to populate ServiceNowTable. Prefixes beyond the default won't be available. The remote server returned an error: (403) Forbidden.

I feel this is not a big issue since I'm explicitly adding the -Table parameter

Screenshots

[gdbarron]

Thanks for the issue @mdehaas. This behavior was due to the difference between table name and table class name. Adding an attachment requires a sysid for the record you are adding to. When retrieving the sysid, if only the number was provided, I would retrieve sys_id and sys_class_name, and use sys_class_name as the table name. This worked....sometimes. In the case of knowledge, the table is kb_knowledge whereas the class is knowledge.

I am no longer relying on sys_class_name. I will attempt to lookup the number prefix in the known list of tables ($ServiceNowTable) and if not found, an error will be thrown. This can now be overridden by providing -Table directly. I've also added the kb_knowledge table to the list of known tables so you can call functions with -Id KB0012334 and -Table is no longer required.

You also mention the ticket table with a prefix of 'TDO', but a quick review of my instance shows the prefix is 'TKT'. Can you confirm?

-GetAllTable relies on the user having permissions to the sys_number table which many folks do not have. This is why it's not an error and processing continues so you are correct that it's not a big deal.

[mdehaas]

Thanks for the quick reply @gdbarron. I've relayed the question to our Servicenow team but got an out-of-office from the person who will most likely know the answer if we customized this or if this is an inheritance of an older release of Servicenow. I'll get back to you as soon as I have the answer.

[gdbarron]

Sounds good. I'll close the PR for now as it's fully usable as is providing Table and ID.

[mdehaas]

Hi @gdbarron,

Our Servicenow specialist confirms the prefix is customized in our environment. So I think the value you are seeing is the default as per Servicenow.

[gdbarron]

@mdehaas, thanks for following up. I'll leave this out of the set of known tables/prefixes; you'll just need to provide -Table in addition to -Id.