Download the PHP package magepsycho/magento2-async-bulk-operations-ui without Composer

Overview

Magento 2 Async Bulk Operations UI extension gives you a complete admin view of everything Magento_AsynchronousOperations is doing in your store.

Magento Open Source does ship a Bulk Actions grid, but it only shows bulks created by the admin who is logged in, reports a bulk as failed the moment one operation fails, and offers no counts, no progress and no aggregate view. This extension replaces that narrow window with two full grids and a status dashboard — so "did the import finish", "which topic keeps failing" and "what is still queued" are answerable at a glance.

Key Features

• Lists every bulk — whichever admin, integration or cron created it
• Derives bulk status from operation counts instead of MAX(status), so one failure no longer hides work still in progress
• Shows complete / failed / open counts and a progress percentage per bulk
• Adds a dedicated operations log across all bulks, filterable by topic, status and error code
• Dashboard with KPI tiles, per-day stacked bars and status doughnuts
• Inspects the request payload and stored response of any single operation, formatted, in a modal
• Retries failed operations safely, including a workaround for a core bug that strands bulks "In Progress" forever
• Separate ACL resources for viewing, retrying and deleting
• CSV / Excel export on both grids

Feature Highlights

Every Bulk, Not Just Yours

Pages

Only the bulk grid has a menu entry. The operations log is a diagnostic view of the same tables — topic, error code and result message exist only per operation, so it answers questions the bulk grid structurally cannot ("which topic keeps failing", "everything that failed with this message, across all bulks") — but it is not a second daily destination, so it hangs off the grid.

Row actions: View, Retry Failed, Delete. Both state-changing actions post and are confirm-gated. On the operation grids, View Payload opens the request payload and response in a modal.

Dashboard

Rendered above the grid in every layout, drawn with the Chart.js 4.4 bundled in lib/web/chartjs.

• KPI tiles: bulks, bulks in progress, bulks with failures, operations, open, failed, success rate
• Stacked bars: operations per day, split complete / failed / open, over 7 / 30 / 90 / 365 days
• Doughnuts: bulks by status, operations by status

The first payload is embedded in the page; changing the period re-fetches magepsycho_asyncoperationsui/chart/data as JSON.

Days are taken from the parent bulk's start_time, not magento_operation.started_at, which stays null until a consumer picks the operation up — open operations would otherwise have no date. Timestamps come straight from the database and are not converted to the admin locale timezone.

Bulk Details

Every bulk opens onto its own page: the summary counts, its operations with topic, status, error code and result message, and the two state-changing actions.

Payload Inspector

The View Payload action on any operation opens the request payload — pretty-printed and syntax-highlighted — next to the stored response. When an operation failed before returning a body, that is said in words rather than shown as an empty box.

This is the detail core stores and never surfaces: without it, "Invalid product data" is the whole story — with it, you can see which SKU carried the bad attribute set. The request body is unwrapped from the operation envelope, where Magento keeps it JSON-encoded twice inside meta_information.

An empty pane is normal and says so: the consumer clears serialized_data once an operation completes, and result_serialized_data only ever holds the body of a successful synchronous call.

Safe Retry

Retry collects the distinct error codes of the bulk's failed operations and hands them to BulkManagement::retryBulk() — the same thing as ticking every row in the core retry modal. Failed operations stored without an error code cannot be targeted by retryBulk(); they are counted and reported in a notice rather than silently ignored.

Core caveat, worked around here. retryBulk() reopens the operation rows and commits, then publishes. For async.* API topics the publish step throws —

— because the stored payload is not in the shape the message encoder expects on re-publish. Core leaves the operations Open with nothing in the queue, so the bulk reads as In Progress forever. This extension snapshots the affected rows first and restores them if publishing throws, so a failed retry is a no-op with a clear error message. Retry of non-async.* topics is unaffected.

Access Control

ACL resources under System:

• MagePsycho_AsyncOperationsUi::bulk — view both grids and the detail page
• MagePsycho_AsyncOperationsUi::retry — retry failed operations
• MagePsycho_AsyncOperationsUi::delete — delete a bulk

The core grid restricts rows by owner; this one does not, so the ACL resources are the only gate — grant them accordingly.

🛠️ Installation

1 Using Composer (Preferred)

2 Using Modman

3 Using Zip File

• Download the Extension Zip File
• Extract & upload the files to /path/to/magento2/app/code/MagePsycho/AsyncOperationsUi/

After installation by either means, activate the extension with following steps

1. Enable the module

2. Flush the store cache

3. Deploy static content - in Production mode only

4. Go to Admin > SYSTEM > Action Logs > Async Bulk Operations

The extension creates no tables of its own — it reads magento_bulk, magento_operation and admin_user.

Configuration

Stores > Configuration > MagePsycho > Async Bulk Operations

Developer Notes

Grid collections are registered globally, on purpose

etc/di.xml — not etc/adminhtml/di.xml — registers the grid collections on Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory::$collections. Magento_AsynchronousOperations registers its own entries on that same argument in its global etc/di.xml, and an area-scoped array argument replaces the global array rather than merging into it. Declaring these in etc/adminhtml/di.xml unregisters the core handles and breaks the core Bulk Actions page with:

Keep any future data-source registration in the global file.

The admin menu parent is chosen at runtime

etc/adminhtml/menu.xml declares the item under Magento_AsynchronousOperations::system_magento_logging, the "Action Logs" node of Magento Open Source. Adobe Commerce removes that node in Magento_Logging and declares Magento_Logging::system_magento_logging instead, and Magento\Backend\Model\Menu\Builder::getResult() skips every child of a removed parent — which is why the item was invisible on Commerce (#1).

The parent cannot be selected in XML: menu.xml is edition-agnostic, and naming the Commerce node there throws OutOfRangeException on Open Source, taking down the whole admin menu (dependsOnModule does not prevent it — that flag is only read later, by Menu\Item::isDisabled()). So Plugin\Menu\ParentFallbackPlugin swaps the parent on the merged menu config, on menu-cache miss, when the declared one did not survive the merge.

Performance

The bulk grid derives its counts with correlated sub-selects against magento_operation, which is indexed on bulk_uuid. Fine for the page sizes of an admin grid; on installs with millions of operation rows, prefer filtering the grid before sorting on a derived column.

Demo data (development only)

Static analysis

dev/ is excluded from both: it is a standalone CLI script that bootstraps Magento itself, which the Magento2 sniffs and phpstan rightly reject as module code.

Changelog

Version 1.0.1 (2026-08-12)

• Fixed: the admin menu item was not visible on Adobe Commerce, whose Magento_Logging module removes the Open Source "Action Logs" node the item is declared under (#1).

Version 1.0.0 (2026-08-07)

• Initial Release.

Authors

• Raj KB

Contributors

To Contribute

Any contribution to the development of Magento 2 Async Bulk Operations UI is highly welcome.
The best possibility to provide any code is to open a pull request on GitHub.

Need Support?

If you encounter any problems or bugs, please create an issue on GitHub.

Please visit our store for more FREE / paid extensions OR contact us for customization / development services.