[Woland2k]

Description

Adds the Returns module's screens to the new Vue Admin Shell. The module UI is a Module Federation remote for the Admin Shell host, built from src/VirtoCommerce.ReturnModule.Web/vue into plugins/admin-shell. The AngularJS UI is unchanged and keeps working in the classic admin.

What the module UI ships:

• Menu: "Returns" in the Orders section, right after Orders (return:access). The host's default menu has no legacy Returns entry, so nothing is replaced.
• Blades:
  • ReturnsList: all returns, or one order's returns when opened from the order. Search, sort and status filter.
  • ReturnDetails: the return with its order, customer and creator, and its status. The selectable statuses come from the server, since they depend on the return's decision. Status labels use the merchant's translations of the Return.Status dictionary, then the module's own labels. Unsaved edits survive when a child blade saves the return. Its "Items" widget opens the lines.
  • ReturnItems, in two modes:
    • for an order: pick the lines and quantities to return, then "Make return";
    • for a return: edit quantities and prices, and approve or decline each line while the return waits for a decision (return:authorize).
    • It takes its order or return through blade options only, so a page reload doesn't reopen it.
  • ReturnOrders: pick the order a new return is made from (return:create).
• Widget on another module's blade: "Returns" on the Orders module's OrdersDetails blade (return:read, saved orders only), with the order's return count.
• Extension point it uses: orders-details-toolbar, offered by the Orders module's order blade. It adds "Create return" there (return:create).
• Blades of other modules it opens by name:
  • the host's PlatformSettingDictionary, to edit Return.Status (shown with platform:setting:access or platform:setting:update);
  • the Customer module's CustomerContactDetails / CustomerOrganizationDetails, for the customer and the creator. When the Customer module UI isn't installed, a notice shows instead.

Build and packaging:

• The csproj excludes vue/ from the .NET build and copies plugins/ on publish.
• .gitignore ignores the plugins/ build output.

No server change: no schema change, no migrations, no new settings, no new permissions, no new NuGet dependencies.

Companion PRs: VirtoCommerce/vc-module-admin-shell#1 (the host that loads module UIs) and VirtoCommerce/vc-shell#386 (framework fixes the host's patch carries).

Languages: the module UI and the module's server texts (setting and permission names, and the AngularJS admin's texts) come in English, Arabic, Hebrew, German, Spanish, Finnish, French, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Swedish and Chinese. In Arabic and Hebrew the Admin Shell lays the module UI out right to left.

New GraphQL queries and mutations

None. This PR adds no query or mutation.

Changes to existing GraphQL queries and mutations

None.

New public services / interfaces / methods

None. This PR adds no .NET surface. The Vue module exposes its blades to the host by name: ReturnsList, ReturnDetails, ReturnItems and ReturnOrders.

New protected methods (extensibility)

None.

Breaking changes

• Compile time: None.
• Package upgrade: None. No .NET member was removed or renamed, so no [Obsolete] was needed.
• Runtime behavior: None for the AngularJS admin or the API. The Vue UI is new.

New dependencies

• NuGet: None.
• npm (build time only): src/VirtoCommerce.ReturnModule.Web/vue/package.json builds the module UI with @vc-shell/framework 2.6.3-rc.0, Vite and vue-tsc. It is not a runtime or NuGet dependency of the module; only the built plugins/admin-shell output ships.

Note (hand-written search and save): the module UI calls POST /api/return/search and PUT /api/return through a small fetch helper, not through the generated client. ReturnController.SearchReturns is declared as ActionResult<Return>, but it returns a search result. UpdateReturn is untyped, but it returns { id } or a list of validation messages. So the generated client types both wrong. Declaring the real response types (metadata only, the wire format stays the same) and regenerating the client would let the UI drop the helper; that is left for a separate change.

Note (follow-ups): the member-type-to-Customer-blade mapping and the "reload while keeping unsaved edits" logic also exist in other module UIs. They could move to a Customer-owned "open member" blade and a rebase option in the framework's blade form; that is left for a separate change.

References

QA-test:

Jira-link:

https://virtocommerce.atlassian.net/browse/VCST-6327

Artifact URL:

https://vc3prerelease.blob.core.windows.net/packages/VirtoCommerce.Return_3.1006.0-pr-30-525e.zip
🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[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