How to use function parameters to select properties

PowerShell Help
1

I have objects with the following properties:

@{
    Name
    CN
    Member
    Groups
    Description
    Roles
    Department
    Info
    }

I wish to query those properties via a function in a PS script. The function should be so flexible to define which property or properties should be selected. The following shows the function. It is given a list of properties (e.g. name, cn). Then it should select only those given properties.

Function Get-Prop {
param (
		[string]$ItemProp  # this should define which properties to select
	)
	if (!$ItemProp) {Write-Host "No Parameter given"}
	else {
			foreach($item in $ItemList) {
			$item.Properties | select  ????
			}
	}
}

I tried converting the variables into a fitting string for selection, e.g. $ItemProp=“{$.name} {$.cn}, {$_.member}”. This however does not work as PS then interprets the string value as a property value which does of course not exist.

Is there a way to make this work?

2

I don’t get the benefit of such a function compared to a simple Select-Object … :man_shrugging:t3:

You can add all desired properties to an array and provide this to the Select-Object …

$PropertyList = @(
    'Name'
    'CN'
    'Member'
    'Groups'
    'Description'
    'Roles'
    'Department'
    'Info'
)

Get-JC_D1984sObject |
    Select-Object -Property $PropertyList

… or did I get something wrong? :thinking:

3

My wish was to allow for the Properties to be input manually at runtime. Then the caller can choose freely which property set he wishes to select. That is the reason behind it.

4

Hmmm … but you have to have an object first … how would you populate $ItemList in your function?

The properties look like they are from AD objects. You may elaborate a little more detailed what you want to do. There might be a better way. :wink:

If you want to wrap this in a function you may provide a list / an array of strings [string[]] - not a single string [string] as input value for your parameter -ItemProp.

Here you can read more about parameters:

5

Correct - it has connection to AD where certain LDAP searches are running in the background. Goal would be to a) populate the searches accordingly (this works already) and b) use only a certain set of properties from the searches.
And it is supposed to run without the AD package for PS. That is why the LDAP searches are in place.

Maybe the approach was wrong. Perhaps it would be better to have more Get functions. Those then each have a specific set of properties.

6

If you already have some working code you may share it here along with a detailed explanation what you would like to change or improve.

We don’t know yet because you did not explain what you actually want to do. :man_shrugging:t3:

When you already collected all the needed information why not show all of them? Who is going to use your code? Are they used to use a command line interface?

7

An example of the function Get-Prop is shown in my first posting here. This function was supposed to work depending on parameter input which property to display. As you already recognized, the idea is to get information of certain AD objects. Since properties are different between different AD object types the selection should be flexible. Therefore the initial idea was to have a function that gets the properties which are given to it via parameter. Question is if and how that is feasible.

8

That’s actually my point …

Display property OF WHAT??? You want to provide a list of properties but you do not provide any object the properties belong to?!?!? :man_shrugging:t3:

That’s why it does not make sense to use one function for all. :man_shrugging:t3:

Your explanation is still way TOO VAGUE AND GENERAL. If you want some help you should start showing your actual code.

And who will give this to your function? Who is going to use your function?

At the moment with the given information I’d say “No, it is not”.

9

AD groups, users etc. So for example an AD group queried does provide the following properties:

cn
samaccounttype
objectguid
objectcategory
objectclass
dscorepropagationdata
name
usnchanged
distinguishedname
grouptype
whencreated
samaccountname
objectsid
instancetype
adspath
usncreated
whenchanged

A user is somewhat different.

What the PS should do (and therefore I won’t copy all coding here) is to allow for nested functions. A user inputs that he would like to query the groups, maybe even if a specific one can be found. This input goes to function a which in turn fills the LDAP filter (works) and then calls a function for the search. If the search was successful the user should then decide which properties are of interest for him for his specific search. Granted, I could always print all and be done with it. But it is supposed to be a little bit forthcoming and flexible.

So the question remains for me: Can I take user input in order to filter object output. For the above example with the groups this could be cn, samaccounttype for one user but cn, whencreated and whenchanged for another. Given your last answer I believe this is not doable.

10

!! Since you refuse to answer my questions this will be my last reply on this topic.

You can do whatever you like - it’s a free world. :man_shrugging:t3: The question for me would be if it makes any sense and does it make the job any better? With the given information to me it does not make any sense at all to pipe the output of different commands to one function to filter for specific properties when you can achieve the same with a simple Select-Object. And you can make this flexible by providing the list of properties you’re after to this Select-Object. :man_shrugging:t3: :man_shrugging:t3: :man_shrugging:t3: :man_shrugging:t3: :man_shrugging:t3: