-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Add Shopware actions for order management #18874
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.
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
Conversation
- Implemented actions to create, retrieve, list, update orders, and manage payment and shipping methods. - Introduced utility functions for parsing objects and constants for pagination limits. - Enhanced prop definitions in the Shopware app for better integration and usability.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
WalkthroughAdds a Shopware integration: app core with API helpers, propDefinitions, pagination, utilities/constants, package bump, and seven new action modules for creating, retrieving, updating, and listing orders, payment methods, and shipping methods. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Action as Action Module
participant App as Shopware App
participant API as Shopware REST API
User->>Action: Invoke action (create/get/update/list)
Action->>Action: Normalize inputs (parseObject, parseFloat)
Action->>App: Call app method (createOrder/getOrder/updateOrder/list*)
App->>App: Build request (_apiUrl, _getHeaders, _makeRequest)
App->>API: HTTP request (GET/POST/PATCH)
API-->>App: Response
App-->>Action: Return data
Action->>User: Export summary + data
sequenceDiagram
participant Action as List Action
participant App as Shopware App
participant Paginate as paginate Generator
participant API as Shopware REST API
Action->>App: Request list (with maxResults)
App->>Paginate: Start paginate(fn, params, maxResults)
loop pages
Paginate->>API: Fetch page (limit/offset)
API-->>Paginate: Page results
Paginate->>Paginate: Yield/accumulate items
alt reached maxResults
Paginate->>Paginate: Stop iteration
end
end
Paginate-->>App: Return aggregated array
App-->>Action: Return data
Action->>User: Export summary (count) + data
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 10
🧹 Nitpick comments (6)
components/shopware/common/constants.mjs (1)
1-1: LGTM. Keep this as the single source of truth for pagination.Minor: import and use this LIMIT in list-orders’ default to avoid drift, and verify shopware.app.mjs imports it where used.
components/shopware/actions/list-orders/list-orders.mjs (1)
1-38: Reuse shared LIMIT and guardmaxResults.Avoid duplicating the default and add a small guard for invalid values.
Apply this diff:
-import shopware from "../../shopware.app.mjs"; +import shopware from "../../shopware.app.mjs"; +import { LIMIT } from "../../common/constants.mjs"; @@ maxResults: { type: "integer", label: "Max Results", description: "The maximum number of orders to return", - default: 100, + default: LIMIT, optional: true, }, }, async run({ $ }) { - const orders = this.shopware.paginate({ + const max = Number.isFinite(this.maxResults) && this.maxResults > 0 ? this.maxResults : LIMIT; + const orders = this.shopware.paginate({ $, fn: this.shopware.listOrders, - maxResults: this.maxResults, + maxResults: max, });components/shopware/actions/create-order/create-order.mjs (1)
10-14: Incorrect hint: writes should not be marked read-only.Set
readOnlyHintto false for this mutating action.annotations: { destructiveHint: false, openWorldHint: true, - readOnlyHint: true, + readOnlyHint: false, },components/shopware/actions/list-payment-methods/list-payment-methods.mjs (1)
24-37: LGTM with a small ergonomics tweakLooks good. Optional: if maxResults is set and small, consider passing a smaller per-page limit to reduce server roundtrips (handled in paginate). No blockers.
components/shopware/actions/list-shipping-methods/list-shipping-methods.mjs (1)
24-37: LGTMConsistent with the other list action. Same optional note about letting paginate use a tighter page size when maxResults is small.
components/shopware/actions/update-order/update-order.mjs (1)
23-37: Confirm tagIds input shape with withLabelYou map tagIds assuming [{ value, label }]. Ensure the prop actually returns that shape (withLabel: true) from the propDefinition. If not guaranteed, guard for strings/IDs.
- tags: parseObject(this.tagIds)?.map(({ value, label }) => ({ - id: value, - name: label, - })), + tags: (parseObject(this.tagIds) ?? []).map((t) => + typeof t === "string" ? ({ id: t }) : ({ id: t.value ?? t.id, name: t.label ?? t.name }) + ),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
components/shopware/actions/create-order/create-order.mjs(1 hunks)components/shopware/actions/get-order/get-order.mjs(1 hunks)components/shopware/actions/list-orders/list-orders.mjs(1 hunks)components/shopware/actions/list-payment-methods/list-payment-methods.mjs(1 hunks)components/shopware/actions/list-shipping-methods/list-shipping-methods.mjs(1 hunks)components/shopware/actions/update-order/update-order.mjs(1 hunks)components/shopware/common/constants.mjs(1 hunks)components/shopware/common/utils.mjs(1 hunks)components/shopware/shopware.app.mjs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (7)
components/shopware/common/constants.mjs (1)
components/shopware/shopware.app.mjs (1)
LIMIT(15-20)
components/shopware/actions/create-order/create-order.mjs (2)
components/shopware/common/utils.mjs (2)
parseObject(1-24)parseObject(1-24)components/shopware/actions/update-order/update-order.mjs (1)
data(70-90)
components/shopware/actions/list-payment-methods/list-payment-methods.mjs (1)
components/shopware/actions/list-shipping-methods/list-shipping-methods.mjs (2)
response(25-29)data(31-31)
components/shopware/actions/list-shipping-methods/list-shipping-methods.mjs (2)
components/shopware/actions/list-payment-methods/list-payment-methods.mjs (2)
response(25-29)data(31-31)components/shopware/actions/list-orders/list-orders.mjs (1)
data(31-31)
components/shopware/shopware.app.mjs (2)
components/shopware/common/constants.mjs (2)
LIMIT(1-1)LIMIT(1-1)components/shopware/actions/update-order/update-order.mjs (1)
data(70-90)
components/shopware/actions/update-order/update-order.mjs (2)
components/shopware/actions/create-order/create-order.mjs (1)
parseObject(83-101)components/shopware/common/utils.mjs (2)
parseObject(1-24)parseObject(1-24)
components/shopware/common/utils.mjs (1)
components/shopware/actions/create-order/create-order.mjs (1)
parseObject(83-101)
⏰ 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). (4)
- GitHub Check: pnpm publish
- GitHub Check: Publish TypeScript components
- GitHub Check: Verify TypeScript components
- GitHub Check: Lint Code Base
🔇 Additional comments (2)
components/shopware/actions/get-order/get-order.mjs (1)
3-31: Verify PR objective and Shopware APIuseNumberAsIdparameter support.The review comment asserts that the PR objective requires supporting order lookup by number using
?useNumberAsId=true, but this requirement is not documented in the codebase. Additionally,useNumberAsIddoes not appear anywhere in the Shopware component, and there is no evidence that the Shopware API supports this parameter.Before applying the suggested changes:
- Confirm the actual PR objective requires dual-lookup (ID or order number)
- Verify the Shopware Admin API documentation supports the
useNumberAsIdquery parameter- If confirmed, the method signature already supports params forwarding, so the diff is feasible
components/shopware/shopware.app.mjs (1)
218-229: Review comment is incorrect—component consistently targets Shopware 6 Admin APIThe codebase is uniformly designed for Shopware 6 Admin API. All 11 API methods (order, tag, rule, currency, customer-address, sales-channel, state-machine, payment-method, shipping-method, etc.) use hyphenated endpoint names consistent with Shopware 6 Admin API format. OAuth bearer authentication (line 143) and the API URL construction (line 139) confirm Shopware 6. Action documentation references link exclusively to the Shopware Admin API. There is no version mismatch, mixed-version logic, or need for Shopware 5 support.
Likely an incorrect or invalid review comment.
…tion and variable names in update-order action for clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
♻️ Duplicate comments (2)
components/shopware/actions/update-order/update-order.mjs (2)
7-7: Copy edit: capitalize “Order” (resource name).Align with Shopware resource naming.
- description: "Partially update information about an order resource. [See the documentation](https://shopware.stoplight.io/docs/admin-api/3cc867261ff28-partially-update-information-about-a-order-resource)", + description: "Partially update information about an Order resource. [See the documentation](https://shopware.stoplight.io/docs/admin-api/3cc867261ff28-partially-update-information-about-a-order-resource)",
10-14: This is a write action — set readOnlyHint: false.The action mutates orders; mark as not read‑only.
annotations: { destructiveHint: false, openWorldHint: true, - readOnlyHint: true, + readOnlyHint: false, },
🧹 Nitpick comments (1)
components/shopware/actions/update-order/update-order.mjs (1)
62-67: Tighten internalComment description.Clearer phrasing.
- description: "Comments given by the internal user", + description: "Internal notes (visible to staff only)",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
components/shopware/actions/create-order/create-order.mjs(1 hunks)components/shopware/actions/update-order/update-order.mjs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- components/shopware/actions/create-order/create-order.mjs
🧰 Additional context used
🧬 Code graph analysis (1)
components/shopware/actions/update-order/update-order.mjs (1)
components/shopware/common/utils.mjs (2)
parseObject(1-24)parseObject(1-24)
⏰ 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). (4)
- GitHub Check: Lint Code Base
- GitHub Check: pnpm publish
- GitHub Check: Publish TypeScript components
- GitHub Check: Verify TypeScript components
🔇 Additional comments (2)
components/shopware/actions/update-order/update-order.mjs (2)
1-3: All sanity checks pass - no issues found.The imports, method, and propDefinitions are correctly defined:
shopware.app.mjsexposesupdateOrdermethodpropDefinitionentries fororderId,tagIds, andruleIdsall existtagIdsincludeswithLabel: truesupport in the action props- The action correctly references these props and calls the method
4-9: Now let me check if there's any reference to issue 18030 or PR description that clarifies the objective:The review comment is incorrect—it conflates Shopware 5 REST API with Shopware 6 Admin API.
The current implementation correctly targets Shopware 6 Admin API, as evidenced by the stoplight.io documentation link in the code. Shopware 5 REST API supports PUT /api/orders with fields like paymentStatusId, orderStatusId, trackingCode, comment, transactionId, and clearedDate, but Shopware 6 uses a fundamentally different architecture:
- In Shopware 6, tracking codes are managed via order deliveries using GET /api/order/{orderId} to fetch delivery IDs, then PATCH /api/order-delivery/{deliveryId}
- Order and payment state management in Shopware 6 uses the state machine with a stateId field, not direct
paymentStatusIdandorderStatusIdfieldsThe fields currently implemented (orderNumber, affiliateCode, campaignCode, customerComment, internalComment, tagIds, ruleIds) are all valid for the Shopware 6 Admin API order update endpoint referenced in the code.
Without access to issue #18030, it's unclear whether the PR should support Shopware 5, Shopware 6, or both. However, the current implementation is consistent with Shopware 6 Admin API specs and does not contain the errors claimed in the review.
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple comments about prop descriptions. Moving to QA since they don't affect functionality.
Co-authored-by: michelle0927 <[email protected]>
…n to include examples for better clarity.
|
/approve |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
♻️ Duplicate comments (1)
components/shopware/actions/create-order/create-order.mjs (1)
97-97: Critical: wrong prop name—currencywill always be undefined.The prop is
currencyObject, notcurrency. This payload field will be omitted or undefined.- currency: parseObject(this.currency), + currency: parseObject(this.currencyObject),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
components/shopware/actions/create-order/create-order.mjs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
components/shopware/actions/create-order/create-order.mjs (2)
components/shopware/actions/update-order/update-order.mjs (1)
parseObject(70-90)components/shopware/common/utils.mjs (2)
parseObject(1-24)parseObject(1-24)
⏰ 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). (3)
- GitHub Check: Publish TypeScript components
- GitHub Check: Verify TypeScript components
- GitHub Check: Lint Code Base
Resolves #18030
Summary by CodeRabbit