non-powershell experience with getting field values from Get-MgSiteListItem

[o-o00o-o]

I can see from this #764 that we have to go to the AdditionalProperties to get the field values for a list these which is functional but not in keeping with the nature of this SDK - i.e. it isn't very powershell.

It seems to be that 99% of the time this function will be used to get the field values Get-MgSiteListItem - is there a reason why these haven't been wrapped and presented as PSObjects? It just makes for a more difficult experience as we now have to navigate hashtables as well as psobjects - it would be great if it could be consistent.

[o-o00o-o]

To work around this I am having to do things like the following

```powershell
$listItems = Get-MgSiteListItem -SiteId $SiteUri -ListId 'The List' -select 'fields' -ExpandProperty 'fields'

# Exclude all the system fields
$listItemValues =
    $listItems.fields.AdditionalProperties |
    ForEach-Object {New-Object PSObject -Property $_} |  ### THIS ONLY NEEDED AS AdditionalProperties is a Hashtable instead of a PSObject
    Select-Object -ExcludeProperty '@odata.etag','_ComplianceFlags','_ComplianceTag','_ComplianceTagWrittenTime','_ComplianceTagUserId','_UIVersionString','LinkTitle','LinkTitleNoMenu','Modified','Created','ContentType','Edit','FolderChildCount','ItemChildCount','Attachments','AuthorLookupId','EditorLookupId'

[peombwa]

Thanks for bringing this to our attention.

The type of AdditionalProperties is set by the code generator, Azure's AutoREST, and is something we can't change. Both Az PowerShell and our module currently represent AdditionalProperties as hashtable.

A hashtable is a valid PowerShell type that provides a few advantages over an object. With a hashtable, you must enumerate over the collection to access its elements.

What you have in your workaround is exactly how a hashtable is meant to be cast into a PSCustomObject. Alternatively, you can look at the workaround in https://stackoverflow.com/questions/72384632/possible-to-pull-info-from-additionalproperties-dictionary-with-microsoft-graph.

I agree with you that using a hashtable is tedious, and I'll surface this to the AutoREST to see if we can simplify the use of AdditionalProperties.

[o-o00o-o]

Thanks @peombwa. So you are saying that AutoREST is producing mixed PSObject and hashtable experience in the produced object? I'm sure they are doing that for some reason but it feels like consistently producing one or the other would create easier to use models.

I don't think I'd mind whether a PSObject or Hashtable, just as long as it was consistennt. The two work quite differently and most people are not PowerShell experts, they are using it to get an automation job done.

I'm willing to bet that >90% of users of this API will be trying to get to the column values of their list.
Using this component took several hours longer than it could have done because of this (and the difficultly to easily get contact information) , hence my feedback.

Better, more discoverable, documentation focused on these issues would be the second best option here.

Thanks for supporting improvements to this area.

[danielniccoli]

provides a few advantages over an object

Which advantages? Because I see only disadvantages. PowerShell works with PSObjects/PSCustomObjects everywhere and getting hastables and dictionaries as a result, when PSObjects/PSCustomObjects are idiomatic to PowerShell is a terrible developer experience.

The type of AdditionalProperties is set by the code generator, Azure's AutoREST, and is something we can't change.

I'd argue you chose the wrong tool, then.