Enhancement: remove blockEdit and blockDelete options as they do not have effect on spo list retentionlabel set

[martinlingstuyl]

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.

[nicodecleyre]

Hi @martinlingstuyl , found an article about setting the label through CSOM and there he came to the same conclusion that the blockDelete and blockEdit parameter get ignored: http://www.myfatblog.co.uk/index.php/2018/05/configuring-default-office-365-labels-using-powershell

apart from the last three which relate to making the tag deletable or editable but also appear to have no effect at all.

On the other hand I don't see why a retention policy should be able to be overruled at list level since this is not possible in the UI as far as I know

[martinlingstuyl]

Thanks @nicodecleyre, that's helpful.

On the other hand I don't see why a retention policy should be able to be overruled at list level since this is not possible in the UI as far as I know

I agree with you that it does not seem helpful. The fun thing is: overriding them at item level IS possible. (Aside from whether you should want such a thing)

Conclusion: we can remove the options here as they don't have effect anyhow.

[waldekmastykarz]

Conclusion: we can remove the options here as they don't have effect anyhow.

Unfortunately that means introducing a breaking change, which can't just do. Even if these options don't do anything, right now, the command completes. If we remove them, it would break with an error that you used unknown option. Because of this, we can't remove them.

I suggest we add a deprecation warning in the code and docs, and mark them for removal in v7.

Also, I removed the bug label, because it's something that's not supported in the API, which we can't fix.

[martinlingstuyl]

If we remove them, it would break with an error that you used unknown option. Because of this, we can't remove them.

Ok, good point: I'll create an issue for a deprecation notice and leave this one open for v7.

[martinlingstuyl]

Opening this up as we are releasing v7 after the summer holidays. Warmly recommended for your contribution. 🎉
Target the v7 branch when raising a PR.

[MathijsVerbeeck]

🙋‍♂️

[MathijsVerbeeck]

@martinlingstuyl I've noticed that the option label is also deprecated. Should this be removed from the command as well?

Also, the name of this command has been changed from spo list retentionlabel set to spo list retentionlabel ensure.

[martinlingstuyl]

Jep @MathijsVerbeeck, deprecated option can be removed, and the command alias retentionlabel set can also be removed.