feat(gooddata-sdk): [AUTO] Add IP allowlist policy CRUD endpoints to metadata API

[yenkins-admin]

Summary

Added IP allowlist policy CRUD endpoints to the SDK via raw HTTP calls. Created CatalogIpAllowlistPolicy and CatalogIpAllowlistPolicyAttributes model classes, added _do_json_request to GoodDataApiClient as a method-agnostic JSON:API HTTP helper, wired up 7 service methods on CatalogOrganizationService (get, list, create, update, delete, add_targets, remove_targets), exported both new classes from gooddata_sdk.init, and added an integration test covering the create/get/list/update/delete lifecycle.

Impact: new_feature | Services: metadata

Source commits (gdc-nas):

• 147ec88 by Peter Plocháň — Merge pull request #22741 from gooddata/dnik/md-allowlist-crud

Files changed

• packages/gooddata-sdk/src/gooddata_sdk/catalog/organization/entity_model/ip_allowlist_policy.py
• packages/gooddata-sdk/src/gooddata_sdk/catalog/organization/service.py
• packages/gooddata-sdk/src/gooddata_sdk/client.py
• packages/gooddata-sdk/src/gooddata_sdk/__init__.py
• packages/gooddata-sdk/tests/catalog/test_catalog_organization.py

Agent decisions

Decisions (4)

raw HTTP instead of generated client — Use _do_json_request on GoodDataApiClient (requests.request wrapper) for all IP allowlist policy calls

• Alternatives: Set status=error and wait for api-client regeneration, Use api_client.call_api() directly from the service
• Why: The generated gooddata-api-client does not yet contain JsonApiIpAllowlistPolicy* models. Per instructions, the preferred path for genuinely new endpoints when the generated client is missing symbols is to wrap raw HTTP on client.py.

not inheriting from Base — CatalogIpAllowlistPolicy uses plain @attrs.define without inheriting catalog.base.Base

• Alternatives: Inherit Base and override to_api / from_api, Inherit Base and leave client_class returning NotImplemented
• Why: Base.to_api() delegates to self.client_class().from_dict() which requires a generated model class. Without generated models, overriding both to_api() and from_api() while still inheriting Base adds confusion. Using @attrs.define directly keeps serialisation explicit and self-contained.

_do_json_request placement — Added _do_json_request as a private method on GoodDataApiClient in client.py

• Alternatives: Expose _api_client property and call api_client.call_api() from the service, Use requests directly inside service.py
• Why: Consistent with the existing _do_post_request pattern. Keeps auth header assembly in one place. Survives api-client regeneration cleanly.

skipped targets integration test — Rely on existing crud cassette; add_targets / remove_targets omitted from integration test

• Alternatives: Add a second integration test covering add_targets / remove_targets
• Why: Test discipline cap is one integration test per cluster. The add/remove targets actions are 204 No Content calls; the serialisation path contains no branching logic that warrants a separate test.

Assumptions to verify (4)

• JSON:API shape for ipAllowlistPolicy entities follows the standard GoodData pattern: {data: {id, type, attributes: {allowedSources: [str]}}}.
• The addTargets / removeTargets action endpoints accept {targets: [{id, type}]} and return 204 No Content.
• PUT on /api/v1/entities/ipAllowlistPolicies/{id} returns the updated entity document (200 or 201 with body).
• The entity type string in the JSON:API body is 'ipAllowlistPolicy' (camelCase, singular).

Risks (3)

• If the server returns a different JSON:API type string (e.g. 'ip-allowlist-policy' with hyphens), to_api() will send the wrong type and PUT/POST may fail validation.
• If PUT returns 204 No Content instead of 200/201 with a body, response.json()['data'] will raise KeyError; update_ip_allowlist_policy would need to fall back to a follow-up GET.
• The _do_json_request method does not replay custom SSL cert or proxy settings from GoodDataApiClient._api_config; only custom_headers are forwarded.

Layers touched (3)

• entity_model — New file: CatalogIpAllowlistPolicy + CatalogIpAllowlistPolicyAttributes without Base inheritance; custom from_api / to_api backed by raw dicts because the generated client models are absent.
  • packages/gooddata-sdk/src/gooddata_sdk/catalog/organization/entity_model/ip_allowlist_policy.py
• public_api — 7 new service methods on CatalogOrganizationService; _do_json_request on GoodDataApiClient.
  • packages/gooddata-sdk/src/gooddata_sdk/__init__.py
  • packages/gooddata-sdk/src/gooddata_sdk/catalog/organization/service.py
  • packages/gooddata-sdk/src/gooddata_sdk/client.py
• tests — Integration test test_ip_allowlist_policy_crud covering create/get/list/update/delete lifecycle.
  • packages/gooddata-sdk/tests/catalog/test_catalog_organization.py

OpenAPI diff

--- a/gooddata-metadata-client.json
@@ -7122,6 +7184,21 @@
+      "IpAllowlistPolicyTargets": {
+        "description": "Target delta for IP allowlist policy actions.",
+        "properties": { "targets": { "items": { "$ref": "#/components/schemas/AssigneeIdentifier" }, "type": "array" } },
+        "required": ["targets"], "type": "object"
+      },
@@ -16070,6 +16147,230 @@
+      "JsonApiIpAllowlistPolicyIn": { ... },
+      "JsonApiIpAllowlistPolicyInDocument": { ... },
+      "JsonApiIpAllowlistPolicyOut": { ... },
+      "JsonApiIpAllowlistPolicyOutDocument": { ... },
+      "JsonApiIpAllowlistPolicyOutIncludes": { ... },
+      "JsonApiIpAllowlistPolicyOutList": { ... },
+      "JsonApiIpAllowlistPolicyOutWithLinks": { ... },
@@ -28272,6 +28549,76 @@
+    "/api/v1/actions/ipAllowlistPolicies/{id}/addTargets": {
+      "post": { "operationId": "addTargets", "summary": "Add targets to IP allowlist policy", "responses": { "204": { "description": "No Content" } } }
+    },
+    "/api/v1/actions/ipAllowlistPolicies/{id}/removeTargets": {
+      "post": { "operationId": "removeTargets", "summary": "Remove targets from IP allowlist policy", "responses": { "204": { "description": "No Content" } } }
+    },
@@ -33209,6 +33556,345 @@
+    "/api/v1/entities/ipAllowlistPolicies": {
+      "get": { "operationId": "getAllEntities@IpAllowlistPolicies", "summary": "Get all IpAllowlistPolicy entities", ... },
+      "post": { "operationId": "createEntity@IpAllowlistPolicies", "summary": "Post IpAllowlistPolicy entities", ... }
+    },
+    "/api/v1/entities/ipAllowlistPolicies/{id}": {
+      "delete": { "operationId": "deleteEntity@IpAllowlistPolicies", ... },
+      "get": { "operationId": "getEntity@IpAllowlistPolicies", ... },
+      "put": { "operationId": "updateEntity@IpAllowlistPolicies", ... }
+    },

Workflow run

---

Generated by SDK OpenAPI Sync workflow

[codecov]

Codecov Report

❌ Patch coverage is 90.47619% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.08%. Comparing base (e1d6ad4) to head (46c9d29).

Files with missing lines	Patch %	Lines
...k/src/gooddata_sdk/catalog/organization/service.py	79.31%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1630      +/-   ##
==========================================
+ Coverage   79.03%   79.08%   +0.04%     
==========================================
  Files         231      232       +1     
  Lines       15634    15697      +63     
==========================================
+ Hits        12357    12414      +57     
- Misses       3277     3283       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.