Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AdditionalProperties is confusing #3115

Open
danielniccoli opened this issue Feb 10, 2025 · 1 comment
Open

AdditionalProperties is confusing #3115

danielniccoli opened this issue Feb 10, 2025 · 1 comment
Labels
feedback Question: SDK Service issue status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close

Comments

@danielniccoli
Copy link

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

@danielniccoli danielniccoli added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:feature New experience request labels Feb 10, 2025
@timayabi2020
Copy link
Contributor

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.

Image

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.

@timayabi2020 timayabi2020 added Service issue Question: SDK status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close feedback and removed type:feature New experience request status:waiting-for-triage An issue that is yet to be reviewed or assigned labels Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback Question: SDK Service issue status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close
Projects
None yet
Development

No branches or pull requests

2 participants