Skip to content

feat(gooddata-sdk): [AUTO] Add CustomUserApplicationSetting CRUD endpoints for per-user app settings#1602

Open
yenkins-admin wants to merge 2 commits into
masterfrom
auto/openapi-sync-C006-20260512-r59682
Open

feat(gooddata-sdk): [AUTO] Add CustomUserApplicationSetting CRUD endpoints for per-user app settings#1602
yenkins-admin wants to merge 2 commits into
masterfrom
auto/openapi-sync-C006-20260512-r59682

Conversation

@yenkins-admin
Copy link
Copy Markdown
Contributor

Summary

Added full SDK support for the new CustomUserApplicationSetting CRUD endpoints. Created the entity model class CatalogCustomUserApplicationSetting with helper methods for serializing to the two distinct API document types (POST vs PATCH). Added five service methods to CatalogUserService (list, get, create, update, delete). Exported the new classes from the public __init__.py. Added an integration test covering the full CRUD lifecycle.

Impact: new_feature | Services: gooddata-metadata-client

Files changed

  • packages/gooddata-sdk/src/gooddata_sdk/catalog/user/entity_model/custom_user_application_setting.py
  • packages/gooddata-sdk/src/gooddata_sdk/catalog/user/service.py
  • packages/gooddata-sdk/src/gooddata_sdk/__init__.py
  • packages/gooddata-sdk/tests/catalog/test_catalog_user_service.py

Agent decisions

Decisions (3)

document serialization helpers vs document wrapper classes — Added as_post_document() and as_patch_document() directly on the entity class rather than separate CatalogXxxDocument / CatalogXxxPatchDocument wrapper classes

  • Alternatives: Create two separate document wrapper classes (CatalogCustomUserApplicationSettingDocument and CatalogCustomUserApplicationSettingInDocument), Construct API objects inline in the service methods (like api_token create does)
  • Why: The create endpoint requires JsonApiCustomUserApplicationSettingPostOptionalIdDocument while update requires JsonApiCustomUserApplicationSettingInDocument — two different types. A single client_class() can only point to one, so the standard 3-class wrapper pattern doesn't cleanly handle this asymmetry. Consolidating both serialization paths on the entity avoids introducing wrapper classes with confusing client_class() pointing.

camelCase attribute access in from_api — Use ea['applicationName'] / ea.get('workspaceId') (camelCase) when accessing raw API dict in from_api()

  • Alternatives: snake_case keys — incorrect for raw API dicts
  • Why: When _check_return_type=False the response is a raw dict using camelCase keys (as set by the API). Other from_api overrides in the codebase (e.g. CatalogLlmProvider.from_api) also use camelCase key access.

workspace_id as optional kwarg — workspace_id defaults to None in CatalogCustomUserApplicationSettingAttributes and passed to API only when non-None

  • Alternatives: Always send workspace_id even when None
  • Why: The OpenAPI spec marks workspaceId as optional (nullable). Null means user-level scope. The JsonApiCustomUserApplicationSettingInAttributes constructor treats workspace_id as optional, so we gate it with a kwargs dict to avoid sending null explicitly.
Assumptions to verify (4)
  • I assumed entity attributes are returned in camelCase in the raw API response dict when _check_return_type=False (based on api_token pattern and LLM provider from_api examples)
  • I assumed the create operation always supplies an id (our SDK entity requires id), so using PostOptionalId variant with id set is correct
  • I assumed the update endpoint (PATCH) is called update_entity_custom_user_application_settings (not patch_entity_...) based on the entities_api grep output showing that operation_id
  • I assumed demo_user ('demo' user from gd_test_config.yaml) is a safe user to create/delete test settings on, as it has no pre-existing custom settings based on the existing api_tokens test pattern
Risks (2)
  • test_custom_user_application_settings will fail on first cassette recording if the demo user already has settings with id 'test-setting-1' from a previous failed test run — the finally block should clean it up
  • If the PATCH endpoint returns 204 No Content instead of the updated entity, from_api(result.data) will fail — some PATCH endpoints return empty body; needs verification against real server
Layers touched (3)
  • entity_model — New file — CatalogCustomUserApplicationSetting and CatalogCustomUserApplicationSettingAttributes
    • packages/gooddata-sdk/src/gooddata_sdk/catalog/user/entity_model/custom_user_application_setting.py
  • public_api — Five new CRUD service methods + public exports
    • packages/gooddata-sdk/src/gooddata_sdk/catalog/user/service.py
    • packages/gooddata-sdk/src/gooddata_sdk/__init__.py
  • tests — Added test_custom_user_application_settings integration test
    • packages/gooddata-sdk/tests/catalog/test_catalog_user_service.py

Source commits (gdc-nas)

  • 827a35d feat(metadata-api): add CustomUserApplicationSetting endpoint (#22399)
OpenAPI diff
@@ gooddata-metadata-client.json @@
+      "JsonApiCustomUserApplicationSettingIn": { "description": "JSON:API representation of customUserApplicationSetting entity.", "properties": { "applicationName", "content", "workspaceId" } }
+      "JsonApiCustomUserApplicationSettingInDocument": { ... }
+      "JsonApiCustomUserApplicationSettingOut": { ... }
+      "JsonApiCustomUserApplicationSettingOutDocument": { ... }
+      "JsonApiCustomUserApplicationSettingOutList": { ... }
+      "JsonApiCustomUserApplicationSettingOutWithLinks": { ... }
+      "JsonApiCustomUserApplicationSettingPostOptionalId": { ... }
+      "JsonApiCustomUserApplicationSettingPostOptionalIdDocument": { ... }
+    "/api/v1/entities/users/{userId}/customUserApplicationSettings": { "get": { "operationId": "getAllEntities@CustomUserApplicationSettings" }, "post": { "operationId": "createEntity@CustomUserApplicationSettings" } }
+    "/api/v1/entities/users/{userId}/customUserApplicationSettings/{id}": { "get", "patch", "delete" }

Workflow run


Generated by SDK OpenAPI Sync workflow

@codecov
Copy link
Copy Markdown

codecov Bot commented May 12, 2026

Codecov Report

❌ Patch coverage is 93.75000% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.02%. Comparing base (12c8d84) to head (bf2e650).
⚠️ Report is 18 commits behind head on master.

Files with missing lines Patch % Lines
...er/entity_model/custom_user_application_setting.py 91.11% 4 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1602      +/-   ##
==========================================
+ Coverage   78.96%   79.02%   +0.06%     
==========================================
  Files         231      232       +1     
  Lines       15578    15642      +64     
==========================================
+ Hits        12301    12361      +60     
- Misses       3277     3281       +4     

☔ 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant