Add ProtectionMode to Microsoft.Security applicationWhitelistings

[erelh]

Latest improvements:

MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.

Contribution checklist:

• I have reviewed the documentation for the workflow.
• Validation tools were run on swagger spec(s) and have all been fixed in this PR.
• The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

• Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
• adding/removing APIs.
• adding/removing properties.
• adding/removing API-version.
• adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

• If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
  Please follow the link to find more details on API review process.

[openapi-sdkautomation]

In Testing, Please Ignore

[Logs] (Generated from 16c7d5f, Iteration 10)

.NET: test-repo-billy/azure-sdk-for-net [Logs] [Diff]

• Microsoft.Azure.Management.SecurityCenter [Logs] [Instructions]
  • Microsoft.Azure.Management.SecurityCenter.1.0.1.nupkg
  • Microsoft.Azure.Management.SecurityCenter.1.0.1.snupkg

Go: test-repo-billy/azure-sdk-for-go [Logs] [Diff]

• preview/security/mgmt/v1.0 [Logs]
• preview/security/mgmt/v2.0 [Logs]
• preview/security/mgmt/v3.0 [Logs]

Python: test-repo-billy/azure-sdk-for-python [Logs] [Diff]

• azure-mgmt-security [Logs] [Instructions] [Generation PR]
  • azure-mgmt-security-0.3.0.zip
  • azure_mgmt_security-0.3.0-py2.py3-none-any.whl

JavaScript: test-repo-billy/azure-sdk-for-js [Logs] [Diff]

• @azure/arm-security [Logs] [Instructions]
  • azure-arm-security-1.2.0.tgz

[AutorestCI]

Automation for azure-sdk-for-python

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-python#7377

[azuresdkci]

Can one of the admins verify this patch?

[AutorestCI]

Automation for azure-sdk-for-go

A PR has been created for you based on this PR content.

Once this PR will be merged, content will be added to your service PR:
Azure/azure-sdk-for-go#5863

[majastrz]

This seems to represent a mapping from file type (enum) to protection mode which seems like an enum also. Generally, using additionalProperties is discouraged because it makes APIs harder to use. In you case, you could model each file type as an optional property in this object and let the value be a protection mode enum type. This option would preserve the current shape of the object over the wire.

Another option would be to model this as an array of objects with 2 properties: file type and protection mode.

[erelh]

@majastrz , Done

[anuchandy]

There are few potential new ARM errors, property names should be camel case. See this report https://dev.azure.com/azure-sdk/public/_build/results?buildId=114422&view=logs

[majastrz]

Added a comment. Please take a look.

[majastrz]

Signed off from ARM side.

[erelh]

@anuchandy can you please complete the merge ?

[anuchandy]

Please review linter errors related to not using camelcase for property names

[erelh]

i cant make the properties camelCase because they are a defined Enum

[anuchandy]

@erelh The json "property names/keys" over the wire is suppose to follow camelCase. In the server code, it can be camelCase, PasalCase or any format but over wire it is suppose to be in camelCase. For example:

This is valid (address.state)

{
   address: {
     state: 'WA'
  }
}

But below one not, because state in address.State is a property key and should be camel case.

{
   address: {
     State: 'wa'
  }
}

This is based on ARM rule 3016. Adding @majastrz to comment.

[majastrz]

While the property names are logically values of the enum, you can still make them lowerCaseCamelCase. In the backend, you can have case-insensitive parsing, so it shouldn't really be a problem.

[erelh]

in C#, Enum parsing is case sensitive
since this object is defined as a key-value of Enum to Enum, it has to be uppercase

can you please suggest a different method of defining this property ? as it is a key-value

[majastrz]

in C#, Enum parsing is case sensitive
since this object is defined as a key-value of Enum to Enum, it has to be uppercase

can you please suggest a different method of defining this property ? as it is a key-value

In general, there is some control in C# over enum parsing. Unfortunately, that's not possible if you're deserializing as Dictionary<enum1,enum2> unless you customize deserializer settings.

Regardless of that, the API should be designed up-front and the service should then be implemented ot match - not the other way as you're trying here.

ARM is expecting property names to be case insensitive for the most part, so if we made your API case-sensitive, it will be inconsistent. You should change the service to be case-insensitive. One way to do this would be to get rid of the dictionary since you have a small set of properties and simply model it as 4 properties: exe, msi, executable, and script. If something else requires a dictionary then you can easily convert it.

[erelh]

OK, changed
Please complete the PR
Thanks