Retrieving Permissions

Rights that can be granted are called Permissions since DSM DSM 2013.2 - unlike in previous versions, where objects of this type were called Tasks. This chapter describes how to retrieve such Permission-objects.


Hint: For compatibility reasons, the cmdlets for Task-objects (like Get-EmdbTask) are still available. However, during an interactive PowerShell-session you will get a warning to use the new Get-EmdbPermission cmdlet instead.


Examples:


Hint: The execution of these examples requires a connected PowerShell drive.


The cmdlet Get-EmdbPersmission is used to retrieve all Permission-objects. Starting with DSM 7, the resultset not only contains System-Permissions, that are supplied as part of the out-of-box installation, but also userdefined Permissions: 


Get-EmdbPermission


In order to reduce the returned information for example on Permissions containing the string "Manage" in their name, the Path-Parameter can be used:


Get-EmdbPermission -Path "*Manage*"


or alternatively (and more easily) 


Get-EmdbPermission "*Manage*"


To fetch only userdefined Permissions, meaning rights that have not been delivered out-of-the-box as system-objects, the following command can be used:


Get-EmdbPermission | Where-Object {$_.IsSystem -eq $false}


Retrieve the Permission "Read" through its Item-ID (this ID will vary in different DSM environments):


Get-EmdbPermission -ItemID 1


Tip: the alias ID can be used instead of ItemID.


Note: Note that Permission-objects are not part of the context rootDSE and therefore they can be referenced without a full qualified path resp. an absolute path.

Starting with PSX 3.1 there was a new option implemented when retrieving Permission objects. When specifying the SingleItemExpected-switch it is expected, that none or exactly one object is contained in the result. If the retrieval returns more than one object, an error is raised that can be caught and handled in scripts.