Implement more purview commands

[nicodecleyre]

Now that we are working on retention labels it also seems interesting to look at information protection and implement these commands:

• [x] #4423
• [x] #4424
• [x] #4425
• [x] #4426
• [x] #4427
• [x] #4428
• [ ] #4714
• [ ] #4715
• [x] #4716
• [ ] #4717
• [x] #5035

More info

• More info about sensitivity labels
• More info about sensitivity label policy
• More info about threat assessment

These apis for sensitivity labels & sensitivity label policy are currently only available in beta, so these should contain a remark in the documentation

[waldekmastykarz]

If I recall it correctly, @martinlingstuyl suggested that we split sensitivitylabel into two words sensitivity and label, similarly to retention label, right @martinlingstuyl?

[martinlingstuyl]

Well, that's an open discussion @waldekmastykarz. I'm not quite sure.

this is the other thread where we're talking about this

https://github.com/pnp/cli-microsoft365/issues/4145#issuecomment-1381475858

[martinlingstuyl]

Thinking about it: While sensitivity is not really a thing without the word label, the other words tend to get too long. And I think it is clear what is meant.

Im for expanding in the direction of

purview sensitivity label
purview sensitivity policy 
purview retention label
purview retention eventtype
purview retention event
purview threatassessment 

The last one can hardly be shortened, so I'd say keep it like this.

[nicodecleyre]

The retention label commands that we use are not splitted , the same goes for other commands like for example m365 pp aibuildermodel get. Also every split feels like it should be in a new folder in our structure.

I understand the suggestion to split the commands, but for consistency and ease of maintenance, I would suggest to keep the command structure as it is.

[martinlingstuyl]

They are currently not split indeed, but the point is: when looking ahead, will there come a moment when you think: *^^%, we should have split them.

In this case because purview has a lot of 'sections' with completely different functionality, like information protection and record management. And because the other retention commands might need a very long name, like retentioneventtype, if you leave them below the purview root.

[waldekmastykarz]

We only split command names into separate words, when the word describes a group of commands. For m365 pp aibuildermodel get, will we have multiple m365 pp ai commands, or m365 pp aibuilder commands? If not, then we keep aibuildermodel as a single group to make it easier to discover and navigate commands' hierarchy.

[waldekmastykarz]

Im for expanding in the direction of

purview sensitivity label
purview sensitivity policy 
purview retention label
purview retention eventtype
purview retention event
purview threatassessment 

The last one can hardly be shortened, so I'd say keep it like this.

In favor. Shall we add an issue to track this and get this done before we release the current version where we introduced these commands?

[martinlingstuyl]

We already released a few, so this will be refactor and add aliasses. I'll create the issue. 👍

[martinlingstuyl]

In favor. Shall we add an issue to track this and get this done

Slight side note @waldekmastykarz, @nicodecleyre : this would only change on the purview end. The spo commands for applying retention labels would still be called the same, agreed?

spo listitem retentionlabel ensure

Etc

In the future we might also add:

spo web sensitivitylabel ensure

So these command nouns will diverge from the purview management nouns as there's no reason to split the noun here.

[nicodecleyre]

Sounds good to me!

[waldekmastykarz]

@martinlingstuyl it seems odd to me to name the same things differently in different places. I suggest that we choose one convention and use it consistently throughout.

[martinlingstuyl]

Hi @waldekmastykarz, I see what you mean. That would mean we're back to using:

purview retentionlabel <verb>
purview retentioneventtype <verb>
purview sensitivitylabel <verb>
purview sensitivitylabel policy <verb>

Ideas?

[waldekmastykarz]

If breaking up sensitivitylabel for spo commands doesn't make sense, then indeed let's use the naming you've just suggested.

[martinlingstuyl]

Hi @nicodecleyre, this epic is OK. If you like you can spec some issues out. For inspiration you can checkout the issues that where created for the purview retentionlabel commands in epic #4145.

[nicodecleyre]

Hi @nicodecleyre, this epic is OK. If you like you can spec some issues out. For inspiration you can checkout the issues that where created for the purview retentionlabel commands in epic #4145.

Thanks for the info @martinlingstuyl, will spec out some issues shortly!