AdditionalProperties is confusing

[danielniccoli]

Is your feature request related to a problem? Please describe the problem.

The way how the use of the -Property parameter changes the results is confusing.

1. Get-MgGroupMember -GroupId "…"
   Returns and object with a property id
2. Get-MgGroupMember -GroupId "…" -Property "city"
   Returns and object with a dictionary AdditionalProperties with the key city, but property id does not exist.
3. Get-MgGroupMember -GroupId "…" -Property "id","city"
   Returns and object with a property id and a dictionary AdditionalProperties with the key city.

My question is:

1. When id is treated as a standard and immediate property of the returned user object (rather than an additional property), why is it left blank, when you manually add properties to the request and don't include id?
2. Why is there a distinction between immediate properties (id) and additional properties (everything not id)?

Looking at the HTTPS request/response, this makes no sense because all properties are on the same JSON level and there is no distinction between standard and additional properties:

GET https://graph.microsoft.com/v1.0/groups/<GUID>/members?$select=id,department

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects(id,department)",
    "value": [
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "xxx",
            "department": "Sales"
        },
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "yyy",
            "department": "Finance"
        },
        {
            "@odata.type": "#microsoft.graph.user",
            "id": "zzz",
            "department": "Management"
        }
    ]
}

Coming from Active Directory, this behaviour is also unexpected, where the -Properties attribute add the selected properties directly to the user object.

Describe the solution you'd like.

A request Get-MgGroupMember -GroupId "…" -Property "id","city" should return an object with a property id and another property department.

Additional context?

No response

[timayabi2020]

Hi @danielniccoli What you are experiencing is by design because of the SDK's code generator's (https://github.com/Azure/autorest.powershell) way of handling response entities defined in the OpenApi file. Attached is the image of the response entity defined in the open Api file used to generate the cmdlet in question.

Based on the code generator's rules:

1. ThedeletedDateTimeproperty is fine since it has a defined type (string) and this will be displayed in the PowerShell session.
2. AdditionalProperties is a dynamic key-value object, meaning it can hold any type of data (string, int, array, another object). Therefore, AutoREST will not automatically expand additionalProperties because it doesn't know the exact structure.

In summary, for the sdk to display any property, it should have a defined type.

In case you need any further clarifications regarding the API path (/users/{user-id}/memberOf) responsible for this issue, kindly raise an issue here https://developer.microsoft.com/en-us/graph/support so that the API owner can respond to it.

[danielniccoli]

Why is id a immediate property and other properties like city are nested withing additionalProperties?

[timayabi2020]

@danielniccoli I unfortunately don't have visibility about API design decisions hence why I referred you to the graph support team here https://developer.microsoft.com/en-us/graph/support. Please raise the question there.

[danielniccoli]

I don't understand what the Graph support team has to do with that question. The sample response from the Graph API, which I included, does not make a distinction between id and department or any other property like city. So why does the PowerShell SDK treat them differently? Again, Why is id a immediate property and other properties like city are nested within additionalProperties?