MPT-22084 use shortDescription in helpdesk queue fixture

[jentyk]

🤖 AI-generated PR — Please review carefully.

Summary

Fixes the helpdesk E2E queue_data fixture, which built the queue creation payload with the key description. The MPT helpdesk queues API expects shortDescription — the camelCase field used consistently by the other resources (e.g. extensions and products). With the wrong key, the value was never applied to the created queue and the fixture sent a malformed payload.

Changes

• tests/e2e/helpdesk/conftest.py: rename the queue_data payload key description → shortDescription.

Testing

• make check (ruff format/check, flake8, mypy, uv lock --check) — passed.
• Running the helpdesk E2E suite requires live MPT credentials and was not executed as part of this change.

Jira: MPT-22084

Closes MPT-22084

• Fixed helpdesk E2E queue_data fixture to use correct API field name shortDescription instead of description
• Ensures queue creation payload conforms to MPT helpdesk queues API expectations, consistent with other resources

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Run ID: cf6b4621-f815-4e67-97fe-0539496f1d36

📥 Commits

Reviewing files that changed from the base of the PR and between 5fb8a53 and 57f955b.

📒 Files selected for processing (1)

• tests/e2e/helpdesk/conftest.py

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• softwareone-platform/mpt-extension-skills (manual)

📜 Recent review details

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🧰 Additional context used

📓 Path-based instructions (2)

**/*

⚙️ CodeRabbit configuration file

**/*: For each subsequent commit in this PR, explicitly verify if previous review comments have been resolved

Files:

• tests/e2e/helpdesk/conftest.py

**

⚙️ CodeRabbit configuration file

**: # AGENTS.md

Working protocol for any task in this repository:

1. Identify the task type and select only the local repository files that are relevant to that task.
2. Read only those relevant local files before making changes.
3. If any selected local file references shared standards or shared operational guidance that are relevant to the same task, read those shared documents too before proceeding.
4. Treat repository-local documents as repository-specific additions, restrictions, or overrides to shared guidance.
5. If a repository-local rule conflicts with a shared rule, the local repository rule takes precedence.

Python API client for the SoftwareONE Marketplace Platform (MPT) API. Provides synchronous
(MPTClient) and asynchronous (AsyncMPTClient) clients built on httpx, with typed
resource services, mixin-based HTTP operations, and an RQL query builder.

Documentation Reading Order

When applicable, read the repository documentation in this order:

1. README.md — repository overview, quick start, and documentation map
2. docs/usage.md — installation, configuration, Python usage examples, and supported Docker-based commands
3. docs/architecture.md — layered architecture, directory structure, and key abstractions
4. docs/local-development.md — Docker-only setup and execution model
5. docs/testing.md — repository-specific testing strategy and command mapping
6. docs/contributing.md — repository-specific workflow and links to shared standards
7. docs/documentation.md — repository-specific documentation rules
8. docs/unit_tests.md — unit test structure and guidance
9. docs/e2e_tests.md — end-to-end test setup and execution

Then inspect the code paths relevant to the task:

• mpt_api_client/mpt_client.py — public sync and async client entry points
• mpt_api_client/http/ — HTTP clients, services, query state, and reusable mixins
• mpt_api_client/resources/ — domain resource groups such as catalog, commerce, billing, and integrati...

Files:

• tests/e2e/helpdesk/conftest.py

🧠 Learnings (8)

📚 Learning: 2025-12-12T15:02:20.732Z

Learnt from: robcsegal
Repo: softwareone-platform/mpt-api-python-client PR: 160
File: tests/e2e/commerce/agreement/attachment/test_async_agreement_attachment.py:55-58
Timestamp: 2025-12-12T15:02:20.732Z
Learning: In pytest with pytest-asyncio, if a test function uses async fixtures but contains no await, declare the test function as def (synchronous) instead of async def. Pytest-asyncio will resolve the async fixtures automatically; this avoids linter complaints about unnecessary async functions. This pattern applies to any test file under the tests/ directory that uses such fixtures.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-04-02T09:35:03.825Z

Learnt from: jentyk
Repo: softwareone-platform/mpt-api-python-client PR: 269
File: tests/e2e/helpdesk/chats/links/test_sync_links.py:18-18
Timestamp: 2026-04-02T09:35:03.825Z
Learning: In this repository’s test suite, flake8-aaa/flake8-aaa codes use short two-digit suffixes (e.g., `# noqa: AAA01`), not three-digit variants like `AAA001`. If you see `# noqa: AAA01` in a test file (e.g., when the Act step is performed via a pytest fixture rather than inline code), treat it as valid and intentional—do not flag it as an invalid/no-longer-needed noqa, and do not suggest removing it even if Ruff reports `RUF102`, since `AAA` is configured under `tool.ruff.lint.external` and these noqa directives are expected to be preserved.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-01-08T08:34:05.465Z

Learnt from: albertsola
Repo: softwareone-platform/mpt-api-python-client PR: 183
File: tests/e2e/catalog/price_lists/conftest.py:29-30
Timestamp: 2026-01-08T08:34:05.465Z
Learning: In end-to-end tests (e.g., tests/e2e/...), reuse existing API resources for read-only operations and safe mutations to speed up test execution. Reserve isolated fixtures (e.g., created_price_list) for destructive tests that require per-test creation and cleanup. Ensure tests document when a fixture creates/destroys data and clearly indicate which operations are destructive, so tests stay fast and properly isolated.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-01-08T23:38:19.565Z

Learnt from: robcsegal
Repo: softwareone-platform/mpt-api-python-client PR: 186
File: tests/e2e/billing/ledger/charge/test_sync_ledger_charge.py:33-39
Timestamp: 2026-01-08T23:38:19.565Z
Learning: In Python e2e tests under tests/e2e, hardcoded external IDs (e.g., INV12345) are intentional because they come from seeded test data. Ensure the test data seeds consistently include these IDs; if seeds change, update tests accordingly. Prefer using a named constant for such IDs (e.g., INV_EXTERNAL_ID) and document the dependency on seed data to avoid brittle tests.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-02-02T13:05:41.144Z

Learnt from: albertsola
Repo: softwareone-platform/mpt-api-python-client PR: 201
File: tests/unit/resources/accounts/mixins/test_activatable_mixin.py:132-139
Timestamp: 2026-02-02T13:05:41.144Z
Learning: In the mpt-api-python-client repository, tests are configured to use pytest asyncio mode auto, which auto-detects async test functions and runs them without requiring pytest.mark.asyncio. Reviewers should rely on this behavior for all Python test files under tests/, and avoid adding unnecessary asyncio markers in async tests. Ensure test files in tests/ adhere to this convention unless a specific test requires an explicit marker.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-04-02T16:26:46.138Z

Learnt from: albertsola
Repo: softwareone-platform/mpt-api-python-client PR: 275
File: tests/e2e/exchange/currencies/conftest.py:43-43
Timestamp: 2026-04-02T16:26:46.138Z
Learning: In this repo’s Python E2E conftest files, line-specific flake8/wemake suppressions like `# noqa: WPS421` placed inline on individual statements (e.g., on specific `print()` calls in teardown blocks) are intentional and acceptable. When reviewing, avoid suggesting converting these to a file-wide ignore (e.g., adding per-file ignores under `[tool.flake8]` in `pyproject.toml`), since that would over-suppress WPS421 for the entire file. Also treat Ruff `RUF102` about an unknown rule code as expected here when suppressing `WPS421` from wemake-python-styleguide.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-04-06T09:03:34.466Z

Learnt from: albertsola
Repo: softwareone-platform/mpt-api-python-client PR: 277
File: tests/e2e/extensibility/extensions/conftest.py:37-40
Timestamp: 2026-04-06T09:03:34.466Z
Learning: In this repo’s E2E test conftest teardown fixtures, it is intentional to catch `MPTAPIError` broadly (not just 404) and to print a diagnostic message instead of re-raising. This avoids failing the test suite during teardown when a resource cannot be deleted in some scenarios. Do not recommend narrowing the `except` clause in these teardown blocks (e.g., checking `error.status == 404`), unless the fixture is clearly not intended as an E2E teardown diagnostic.

Applied to files:

• tests/e2e/helpdesk/conftest.py

📚 Learning: 2026-04-16T13:00:41.320Z

Learnt from: jentyk
Repo: softwareone-platform/mpt-api-python-client PR: 303
File: tests/e2e/helpdesk/chats/participants/conftest.py:25-31
Timestamp: 2026-04-16T13:00:41.320Z
Learning: In mpt-api-python-client, do not treat list-wrapped arguments to CreateMixin.create() / AsyncCreateMixin.create() as an error. ResourceData is intentionally typed as Resource | list[Resource] (see mpt_api_client/models/model.py), so create() should accept either a single resource dict or a list of resource dicts (e.g., create([chat_participant_data])) to perform a batch create and return a ModelCollection. Therefore, reviewers should only flag list-wrapped create() arguments when there is evidence they violate the expected API contract beyond this documented batch-create behavior.

Applied to files:

• tests/e2e/helpdesk/conftest.py

🔇 Additional comments (1)

tests/e2e/helpdesk/conftest.py (1)

15-15: LGTM!

---

📝 Walkthrough

Walkthrough

The queue_data fixture in the helpdesk e2e test module updates its returned payload to use shortDescription instead of description, aligning the test fixture with the expected queue creation request schema.

Changes

Test Fixture Payload Update

Layer / File(s)	Summary
Queue test data fixture payload update tests/e2e/helpdesk/conftest.py	The queue_data fixture request payload key is renamed from description to shortDescription, updating the schema that downstream e2e tests use when creating queues.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• softwareone-platform/mpt-api-python-client#266: The queue payload schema update aligns with queue fixtures and tests that create queues via created_queue.
• softwareone-platform/mpt-api-python-client#243: The fixture payload field rename from "description" to "shortDescription" directly aligns with helpdesk queue e2e fixtures using that request body field.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Pr And Commit Formatting	✅ Passed	PR #344 title matches ' ' (MPT-22084 ...); description includes Summary/Changes/Testing; 1 Conventional Commits-style commit with a body explaining why; single-commit histor...
Documentation Up To Date	✅ Passed	PR #344 changes only tests/e2e/helpdesk/conftest.py (queue_data key description→shortDescription); no docs update needed since it’s E2E test-only, not documented public behavior.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud