I've been checking the behavior of the --blockEdit and --blockDelete options. These options are slightly odd, they are available in the API for sure, but the functionality is also configured when creating the Purview retention labels themselves.
It seems like you should be able to use blockEdit and blockDelete to override the behavior that you've configured on the purview label. But with the spo list retentionlabel set command the options are ignored. They are communicated to the API fine, but SharePoint ignores their values. When retrieving the list label afterwards, using spo list retentionlabel get, you'll see that the default values that where configured in purview are still visible.
Examples from my tryouts:
As you can see the options do not influence the label properties. While they where communicated to the API:
Suggestion
There is not much documentation on the use of these API's. As it is not working I suggest we remove the two options. I mean, it is actually preferable (and required) to configure these values on the Purview labels in any case. Overriding those values on application seems not really like something you'd typically (want to) do.
I've been checking the behavior of the
--blockEditand--blockDeleteoptions. These options are slightly odd, they are available in the API for sure, but the functionality is also configured when creating the Purview retention labels themselves.It seems like you should be able to use
blockEditandblockDeleteto override the behavior that you've configured on the purview label. But with thespo list retentionlabel setcommand the options are ignored. They are communicated to the API fine, but SharePoint ignores their values. When retrieving the list label afterwards, usingspo list retentionlabel get, you'll see that the default values that where configured in purview are still visible.Examples from my tryouts:
As you can see the options do not influence the label properties. While they where communicated to the API:
Suggestion
There is not much documentation on the use of these API's. As it is not working I suggest we remove the two options. I mean, it is actually preferable (and required) to configure these values on the Purview labels in any case. Overriding those values on application seems not really like something you'd typically (want to) do.