Saleor Update: 3.4 & 3.5 releases and the CLI
We aim to constantly improve Saleor. In April, we released Saleor 3.2 and 3.3 with custom prices in checkout, customizable webhook payloads, a public OIDC plugin, a full-text search for products, and a new API for fetching metadata.
Now, let’s dive deep into what’s new this time.
Saleor CLI
Saleor attracts those who share our passion for innovation. The CLI, even though it’s still a young project, represents our approach to the modern commerce world and our never-ending effort to boost developer productivity with Saleor.
No matter if you’re new to Saleor or already familiar with it and want to test it locally, we highly recommend that you try our recently released Saleor CLI.
It’s designed to boost productivity and improve your development experience with Saleor and Saleor Cloud. You can create your free cloud developer account, new environments, sandbox instances, and a storefront for local purposes within seconds.
To install the latest version of Saleor CLI, please use the following command:
npm i -g saleor@latestYou can create a free developer account with the command below:
saleor registerCreating a storefront demo
If you’re new to Saleor and want to start building locally, the following command will automatically create your new local storefront environment powered by our open-source project called Saleor React Storefront (SRS). Please bear in mind that it’s a starter kit and currently under development.
saleor storefront create --demoYou can read more about the CLI tool in the docs.
Saleor 3.4
Transaction-recording API for external payment support
After checking multiple use cases, we realized that we needed to provide more flexibility to the payment flow. This also goes along with our headless approach.
Our goal was to extract the payment logic outside Saleor. We’ve added new models, types, and mutations responsible for creating and updating transactions related to order/checkout. In this flow, a separate Saleor App handles payments, and Saleor only receives information about it.
As a result, we can support any payment provider more easily or provide a more custom flow.
See the following cases that would address a new payment flow.
Case: Order before payment
Case: Payment before order
Case: Updating transaction
Case: Calling an action from the Saleor side
Observability reporter
The purpose of the observability reporter is to collect information about events related to interactions outside of Saleor. Saleor communicates with an external application in two ways: using webhooks and queries through the GraphQL API. In both cases, the communication may or may not be successful, e.g., Saleor uses a webhook, and the application is not responding. We want to collect all information, whether the communication is successful or not.
When such an event occurs, it creates a report with metadata, draws attention to sensitive data, and compiles it in the completed report (e.g., blurred credit card numbers, etc.). These reports are gathered and regularly sent out using the standard webhook mechanism.
Saleor observability reporter is the basis for building integrations with external observability services. You can learn more about the observability reporter in the following PR.
New webhook events
We’ve added the following asynchronous webhooks related to vouchers, menus, warehouses, and apps.
VOUCHER_CREATEDVOUCHER_UPDATEDVOUCHER_DELETEDMENU_CREATEDMENU_UPDATEDMENU_DELETEDMENU_ITEM_CREATEDMENU_ITEM_UPDATEDMENU_ITEM_DELETEDAPP_CREATEDAPP_UPDATEDAPP_DELETEDAPP_STATUS_CHANGED
Improved metadata permissions for apps
Metadata gives you the possibility to customize your shop without modifying the core. You can extend most of the common models using the metadata API. With the 3.4 release, we improved metadata permissions for apps.
All staff users with a valid app user token can now access the app’s metadata. Previously, Saleor required the manage_apps permission. The access token can be used to read and write the metadata. The same token that gives access to App.publicMetadata doesn’t allow reading other metadata.
Additionally, apps can read their own metadata without the MANAGE_APPS permission. They can also update their own metadata.
Learn more on GitHub.
Saleor 3.4 Changelog
To learn more about what we’ve delivered, please check the 3.4 changelog.
Saleor 3.5
Stock allocation improvements
After delivering the Multichannel and Click & Collect features, we realized there was some room for stock allocation improvements.
We identified the problem with the random warehouse selection by Saleor when multiple warehouses were assigned to a specific sales channel.
Think of a store with a channel and three assigned warehouses. The first warehouse is responsible for global fulfillment and covers online sales. The other two warehouses are local franchises (e.g., separated companies) that allow for Click & Collect.
In that scenario, Saleor was randomly allocating stock in one of the three warehouses described above. A store manager then had to reassign stock manually to the correct warehouse.
With the 3.5 version, we provided a solution to our API. Now it allows assigning warehouses directly to a specific channel.
Plain text attribute
We introduced a plain text attribute to our API. It will also soon be available in the dashboard.
Similar to the rich text attribute, a plain text attribute covers the plain text without any formatting.
New webhook events
Saleor now supports the following new webhook events related to page types, addresses, staff, and attributes.
PAGE_TYPE_CREATEDPAGE_TYPE_UPDATEDPAGE_TYPE_DELETEDADDRESS_CREATEDADDRESS_UPDATEDADDRESS_DELETEDSTAFF_CREATEDSTAFF_UPDATEDSTAFF_DELETEDATTRIBUTE_CREATEDATTRIBUTE_UPDATEDATTRIBUTE_DELETEDATTRIBUTE_VALUE_CREATEDATTRIBUTE_VALUE_UPDATEDATTRIBUTE_VALUE_DELETED
Saleor 3.5 Changelog
You can find the full changelog here.
Thank you
A big thank you to all contributors and community members for each bug report and your feedback!
Follow our Twitter and sign up for our newsletter to stay up to date with the latest info about Saleor!
Cheers!
