Skip to content

add deleteCustomFramework endpoint #2185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
api-clients-generation-pipeline wants to merge 1 commit into from
Closed

add deleteCustomFramework endpoint #2185

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions .apigentools-info
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,13 @@
"spec_versions": {
"v1": {
"apigentools_version": "1.6.6",
"regenerated": "2025-01-13 18:28:06.332663",
"spec_repo_commit": "3517c947"
"regenerated": "2025-01-13 22:02:25.782618",
"spec_repo_commit": "5aa96e08"
},
"v2": {
"apigentools_version": "1.6.6",
"regenerated": "2025-01-13 18:28:06.347841",
"spec_repo_commit": "3517c947"
"regenerated": "2025-01-13 22:02:25.797567",
"spec_repo_commit": "5aa96e08"
}
}
}
108 changes: 108 additions & 0 deletions .generator/schemas/v2/openapi.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -213,6 +213,27 @@ components:
required: true
schema:
type: string
CustomFrameworkHandle:
description: The framework handle.
in: path
name: handle
required: true
schema:
type: string
CustomFrameworkOrgID:
description: The ID of the organization.
in: path
name: org_id
required: true
schema:
type: string
CustomFrameworkVersion:
description: The framework version.
in: path
name: version
required: true
schema:
type: string
EntityID:
description: UUID or Entity Ref.
in: path
Expand Down Expand Up @@ -8375,6 +8396,54 @@ components:
$ref: '#/components/schemas/CustomDestinationResponseDefinition'
type: array
type: object
CustomFrameworkMetadata:
description: Response object for an organization's custom frameworks.
properties:
created_at:
description: Framework Creation Date
format: int64
type: integer
created_by:
description: Framework Creator
type: string
description:
description: Framework Description
type: string
handle:
description: Framework Handle
example: ''
type: string
icon_url:
description: Framework Icon URL
type: string
id:
description: Custom Framework ID
example: ''
type: string
name:
description: Framework Name
example: ''
type: string
org_id:
description: Org ID
example: 0
format: int64
type: integer
updated_at:
description: Framework Update Date
format: int64
type: integer
version:
description: Framework Version
example: ''
type: string
required:
- id
- org_id
- handle
- version
- name
type: object
DORADeploymentRequest:
description: Request to create a DORA deployment event.
properties:
Expand Down Expand Up @@ -9015,6 +9084,12 @@ components:
type: string
x-enum-varnames:
- APPDEFINITIONS
DeleteCustomFrameworkResponse:
description: Delete a custom framework.
properties:
data:
$ref: '#/components/schemas/CustomFrameworkMetadata'
type: object
DependencyLocation:
description: Static library vulnerability location.
properties:
Expand Down Expand Up @@ -40135,6 +40210,39 @@ paths:
operator: OR
permissions:
- org_management
/api/v2/orgs/{org_id}/cloud_security_management/custom_frameworks/{handle}/{version}:
delete:
description: Delete a custom framework.
operationId: DeleteCustomFramework
parameters:
- $ref: '#/components/parameters/CustomFrameworkOrgID'
- $ref: '#/components/parameters/CustomFrameworkHandle'
- $ref: '#/components/parameters/CustomFrameworkVersion'
responses:
'200':
content:
application/json:
schema:
$ref: '#/components/schemas/DeleteCustomFrameworkResponse'
description: OK
'400':
$ref: '#/components/responses/BadRequestResponse'
'429':
$ref: '#/components/responses/TooManyRequestsResponse'
'500':
$ref: '#/components/responses/BadRequestResponse'
security:
- apiKeyAuth: []
appKeyAuth: []
- AuthZ:
- security_monitoring_rules_read
summary: Delete a custom framework
tags:
- Security Monitoring
x-permission:
operator: OR
permissions:
- security_monitoring_rules_read
/api/v2/permissions:
get:
description: Returns a list of all permissions, including name, description,
Expand Down
5 changes: 5 additions & 0 deletions examples/v2/security-monitoring/DeleteCustomFramework.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
# Delete a custom framework returns "OK" response

require "datadog_api_client"
api_instance = DatadogAPIClient::V2::SecurityMonitoringAPI.new
p api_instance.delete_custom_framework("org_id", "handle", "version")
103 changes: 54 additions & 49 deletions features/scenarios_model_mapping.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1726,55 +1726,10 @@
"v2.UploadIdPMetadata" => {
"idp_file" => "File",
},
"v2.ListRoles" => {
"page_size" => "Integer",
"page_number" => "Integer",
"sort" => "RolesSort",
"filter" => "String",
"filter_id" => "String",
},
"v2.CreateRole" => {
"body" => "RoleCreateRequest",
},
"v2.DeleteRole" => {
"role_id" => "String",
},
"v2.GetRole" => {
"role_id" => "String",
},
"v2.UpdateRole" => {
"role_id" => "String",
"body" => "RoleUpdateRequest",
},
"v2.CloneRole" => {
"role_id" => "String",
"body" => "RoleCloneRequest",
},
"v2.RemovePermissionFromRole" => {
"role_id" => "String",
"body" => "RelationshipToPermission",
},
"v2.ListRolePermissions" => {
"role_id" => "String",
},
"v2.AddPermissionToRole" => {
"role_id" => "String",
"body" => "RelationshipToPermission",
},
"v2.RemoveUserFromRole" => {
"role_id" => "String",
"body" => "RelationshipToUser",
},
"v2.ListRoleUsers" => {
"role_id" => "String",
"page_size" => "Integer",
"page_number" => "Integer",
"sort" => "String",
"filter" => "String",
},
"v2.AddUserToRole" => {
"role_id" => "String",
"body" => "RelationshipToUser",
"v2.DeleteCustomFramework" => {
"org_id" => "String",
"handle" => "String",
"version" => "String",
},
"v2.ListFindings" => {
"page_limit" => "Integer",
Expand Down Expand Up @@ -1964,6 +1919,56 @@
"v2.CancelHistoricalJob" => {
"job_id" => "String",
},
"v2.ListRoles" => {
"page_size" => "Integer",
"page_number" => "Integer",
"sort" => "RolesSort",
"filter" => "String",
"filter_id" => "String",
},
Comment on lines +1922 to +1928
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.CreateRole" => {
"body" => "RoleCreateRequest",
},
Comment on lines +1929 to +1931
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.DeleteRole" => {
"role_id" => "String",
},
Comment on lines +1932 to +1934
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.GetRole" => {
"role_id" => "String",
},
Comment on lines +1935 to +1937
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.UpdateRole" => {
"role_id" => "String",
"body" => "RoleUpdateRequest",
},
Comment on lines +1938 to +1941
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.CloneRole" => {
"role_id" => "String",
"body" => "RoleCloneRequest",
},
Comment on lines +1942 to +1945
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.RemovePermissionFromRole" => {
"role_id" => "String",
"body" => "RelationshipToPermission",
},
Comment on lines +1946 to +1949
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.ListRolePermissions" => {
"role_id" => "String",
},
Comment on lines +1950 to +1952
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.AddPermissionToRole" => {
"role_id" => "String",
"body" => "RelationshipToPermission",
},
Comment on lines +1953 to +1956
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.RemoveUserFromRole" => {
"role_id" => "String",
"body" => "RelationshipToUser",
},
Comment on lines +1957 to +1960
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.ListRoleUsers" => {
"role_id" => "String",
"page_size" => "Integer",
"page_number" => "Integer",
"sort" => "String",
"filter" => "String",
},
Comment on lines +1961 to +1967
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.AddUserToRole" => {
"role_id" => "String",
"body" => "RelationshipToUser",
},
Comment on lines +1968 to +1971
Copy link

@datadog-datadog-prod-us1 datadog-datadog-prod-us1 bot Jan 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ Code Quality Violation

Consider using symbols instead of string hash keys (...read more)

In Ruby, it is a best practice to use symbols instead of strings as hash keys. This rule emphasizes that it's more efficient and idiomatic to use symbols for this purpose. Symbols are immutable and unique, which makes them ideal for identifying things, whereas strings are mutable and can create multiple objects for the same sequence of characters.

The importance of this rule lies in the performance and memory usage of your Ruby application. Using symbols as hash keys reduces memory usage because they are stored in memory only once during a Ruby process. This can make a significant difference in the efficiency of your application, especially when dealing with large data sets.

To ensure you're following good coding practices, always use symbols for hash keys unless there's a specific reason to use a string. A simple refactoring from values = { 'foo' => 42, 'bar' => 99, 'baz' => 123 } to values = { foo: 42, bar: 99, baz: 123 } will make your code compliant with this rule. This not only improves your code's performance but also makes it more readable and consistent with Ruby's conventions.

View in Datadog  Leave us feedback  Documentation

"v2.ListPowerpacks" => {
"page_limit" => "Integer",
"page_offset" => "Integer",
Expand Down
18 changes: 18 additions & 0 deletions features/v2/security_monitoring.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -296,6 +296,24 @@ Feature: Security Monitoring
And the response "data.attributes.rule_query" is equal to "type:log_detection source:cloudtrail"
And the response "data.attributes.data_exclusion_query" is equal to "account_id:12345"

@generated @skip @team:DataDog/k9-cloud-security-platform
Scenario: Delete a custom framework returns "Bad Request" response
Given new "DeleteCustomFramework" request
And request contains "org_id" parameter from "REPLACE.ME"
And request contains "handle" parameter from "REPLACE.ME"
And request contains "version" parameter from "REPLACE.ME"
When the request is sent
Then the response status is 400 Bad Request

@generated @skip @team:DataDog/k9-cloud-security-platform
Scenario: Delete a custom framework returns "OK" response
Given new "DeleteCustomFramework" request
And request contains "org_id" parameter from "REPLACE.ME"
And request contains "handle" parameter from "REPLACE.ME"
And request contains "version" parameter from "REPLACE.ME"
When the request is sent
Then the response status is 200 OK

@skip @team:DataDog/k9-cloud-security-platform
Scenario: Delete a non existing rule returns "Not Found" response
Given new "DeleteSecurityMonitoringRule" request
Expand Down
6 changes: 6 additions & 0 deletions features/v2/undo.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1651,6 +1651,12 @@
"type": "idempotent"
}
},
"DeleteCustomFramework": {
"tag": "Security Monitoring",
"undo": {
"type": "safe"
}
},
"ListPermissions": {
"tag": "Roles",
"undo": {
Expand Down
2 changes: 2 additions & 0 deletions lib/datadog_api_client/inflector.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1373,6 +1373,7 @@ def overrides
"v2.custom_destination_update_request" => "CustomDestinationUpdateRequest",
"v2.custom_destination_update_request_attributes" => "CustomDestinationUpdateRequestAttributes",
"v2.custom_destination_update_request_definition" => "CustomDestinationUpdateRequestDefinition",
"v2.custom_framework_metadata" => "CustomFrameworkMetadata",
"v2.cvss" => "CVSS",
"v2.dashboard_list_add_items_request" => "DashboardListAddItemsRequest",
"v2.dashboard_list_add_items_response" => "DashboardListAddItemsResponse",
Expand All @@ -1398,6 +1399,7 @@ def overrides
"v2.delete_apps_response" => "DeleteAppsResponse",
"v2.delete_apps_response_data_items" => "DeleteAppsResponseDataItems",
"v2.delete_apps_response_data_items_type" => "DeleteAppsResponseDataItemsType",
"v2.delete_custom_framework_response" => "DeleteCustomFrameworkResponse",
"v2.dependency_location" => "DependencyLocation",
"v2.deploy_app_response" => "DeployAppResponse",
"v2.deploy_app_response_data" => "DeployAppResponseData",
Expand Down
Loading
Loading