Unable to query request item variables

[f0oster]

Describe the bug Unable to query request item variables.

To Reproduce Steps to reproduce the behavior:

1. Import-Module
2. Set-SNOWAuth -Instance "dev123456" -Credential (get-credential)
3. Get-SNOWRITMVariableSet -number "RITM0631749" -Verbose
4. See error as per below:

   
   VERBOSE: GET https://removed.service-now.com/api/now/v2/table/sc_req_item?sysparm_query=number=RITM0631749&sysparm_fields=sys_id&sysparm_limit=1000&sysparm_offset=0 with 0-byte
   payload
   VERBOSE: received -1-byte response of content type application/json;charset=UTF-8
   VERBOSE: GET
   https://removed.service-now.com/api/now/v2/table/sc_item_option_mtom?sysparm_query=request_item=3b42f52a1ba4f450e49c43bdcc4bcbdc&sysparm_display_value=True&sysparm_exclude_reference_l
   ink=True&sysparm_fields=sc_item_option.item_option_new.name,sc_item_option.item_option_new,sc_item_option.value&sysparm_limit=1000&sysparm_offset=0 with 0-byte payload
   VERBOSE: received -1-byte response of content type application/json;charset=UTF-8

Get-SNOWRITMVariableSet : Cannot bind argument to parameter 'Name' because it is null. At line:1 char:1

• Get-SNOWRITMVariableSet -number "RITM0631749" -Verbose

• 
  + CategoryInfo          : InvalidData: (:) [Get-SNOWRITMVariableSet], ParameterBindingValidationException
  + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Get-SNOWRITMVariableSet
  ```

Expected behavior To see the output of the associated request Item variables from the dotwalked field in the sc_item_option junction table.

Environment (please complete the following information):

• Module Version: 1.1.0
• Powershell Version: 5.1
• OS: Windows 10
• Servicenow Version: [e.g. Tokyo] Sandiego

Additional context Firstly, very cool work on the module. More than likely I will become an active user (maybe a contributor too at some point, if you're open to PRs), given I am tasked with automating a lot of our workload at the moment.

When I manually query the junction table via the Table API, there is no sc_item_option column included in the response. I see the following columns returned: sys_id, sys_updated_by, sys_created_on, sys_mod_count, requested_item (ref field), sys_updated_on, sys_tags, sys_created_by

When I add a filter to explicitly include the field, it is empty. This seems to be the case for all items I've queried so far. Interestingly, when I query a request item via the JSONv2 web service rather than the Table API, all the appropriate variables are listed.

I am starting to suspect that the issue I am seeing does not really relate to the module itself and is more centered around our ServiceNow instance, maybe the ACLs/API configuration. Unfortunately I am not a SN expert, nor am I a SN admin in our environment, so my ability to tinker and test is very limited.

Wondering if you have any advice here.

Thanks, f0oster

[insomniacc]

Hey, really appreciate the feedback! I've had a pretty busy week so haven't been able to get to this yet but since we've got a long weekend here in the UK I should have time to take a look! RITM variables in ServiceNow have always been are super awkward, there's no direct reference on the RITM itself, back in the day I actually used to do this via a scripted rest endpoint, but that wouldn't have been feasible for this module, so I used the dot walk method on the reference table instead. You'd assume that if it was permission related, you wouldn't get a response from querying sc_item_option_mtom at all, rather than some fields and not all, but potentially - I'll have to do some testing on that, and I'm totally open to PR's any contributions are welcome!

[f0oster]

Just confirming, I doubt there's any issue with the module at all. This problem is a configuration issue on our side.

The access was definitely misconfigured by our SN admin (I'm still dealing with this problem). When he was screen sharing, I noted that read access was granted to both sc_req_item and sc_item_option_mtom tables, however it was not granted to either sc_item_option or sc_item_option_new tables.

He was quite persistent on it being configured correctly but eventually I wore him down and he agreed to apply an elevated role for testing sake. The queries started to return the expected fields right away, no surprise. Now I'm just waiting for him to reconfigure the role.

Just a note: it seems that reference fields are omitted entirely from API responses when the user doesn't have permission to read the contents of the referenced table, makes sense I guess. Might come in handy to know in the future.

[insomniacc]

Glad you got it sorted, and thanks for the follow up, I'll add a comment to that effect in the docs