- or
1531 results found
-
Let B2B Employees changed their own password
It should be a standard functionality that a user can change their password.
This is currently not possible.
Please implement this.
2 votes -
Add promotion code via link
It would be a nice feature if discount codes could be redeemed via link in the same way that EasyCoupon does it for example. This would allow merchants to send mails already including a working link to get the customer shopping with their discount. For the customers, this would make the journey smoother because they don't need to back and forth to get some code and find the field to enter it and so on.
Plus, the customer is probably much more likely to actually complete the checkout if they see their shiny discount applied at all times right from the moment they visit the store.
It would be a nice feature if discount codes could be redeemed via link in the same way that EasyCoupon does it for example. This would allow merchants to send mails already including a working link to get the customer shopping with their discount. For the customers, this would make the journey smoother because they don't need to back and forth to get some code and find the field to enter it and so on.
Plus, the customer is probably much more likely to actually complete the checkout if they see their shiny discount applied at all times right from…
6 votes -
Advanced Product Catalogues - Assign Category & Product Visibility Via Pre-Defined "Template"
ENG: Use case: As a shop operator with many categories and products, I don't want to have to individually determine which categories and products a unit should have access to when creating organizational units. Instead, it should be possible to create templates—which may only be usable and visible at the admin level—that can be used to define viewing permissions accordingly. If I then need to create several organizational units, I could simply—where possible—quickly define the permissions using the template without having to manually define the same permissions again and again for each additional organization.
DE: Use-Case: Als Shopbetreiber mit vielen Kategorien und Produkten möchte ich bei der Erstellung einer Organisationseinheiten nicht immer individuell bestimmen müssen, auf welche Kategorien und Produkte ein Einheit Zugriff haben soll. Vielmehr muss es die Möglichkeit gebene, das - ggf. nur auf Adminebene nutzbar und sichtbar - Templates erstellt werden können, über die Sichtberechtigungen entsprechend definiert werden können. Sofern ich dann mehrere Organisationsienheiten erstellen muss, könnte ich dann einfach - wo möglich - die Sichtberechtigungen schnell über das Template festlegen lassen ohne dieselben Berechtigungen abermals für jede weitere Organisatzion manuell festlegen zu müssen.
ENG: Use case: As a shop operator with many categories and products, I don't want to have to individually determine which categories and products a unit should have access to when creating organizational units. Instead, it should be possible to create templates—which may only be usable and visible at the admin level—that can be used to define viewing permissions accordingly. If I then need to create several organizational units, I could simply—where possible—quickly define the permissions using the template without having to manually define the same permissions again and again for each additional organization.
DE: Use-Case: Als Shopbetreiber mit vielen…
3 votes -
Rule-based hiding of Buy button
In Shopware 6, the visibility of products can already be controlled via rules by using the dynamic access extension (up to a certain point, as the stock is not being validated). However, there currently is no native way to hide or disable the “Buy / Add to cart” button based on rules, especially when combining customer groups with product stock conditions.
In B2B and hybrid B2C/B2B scenarios, it is common that products with stock = 0 (with closeout enabled) should still be orderable for specific customer groups, while the buy button should be hidden or disabled for all other customer groups. Moreover it should be possible to set "closeout" on sales channel level.
In Shopware 6, the visibility of products can already be controlled via rules by using the dynamic access extension (up to a certain point, as the stock is not being validated). However, there currently is no native way to hide or disable the “Buy / Add to cart” button based on rules, especially when combining customer groups with product stock conditions.
In B2B and hybrid B2C/B2B scenarios, it is common that products with stock = 0 (with closeout enabled) should still be orderable for specific customer groups, while the buy button should be hidden or disabled for all other customer…
3 votes -
Filter visibility by selected sales channels
For products, there is an option to set visibility for selected sales channels.
This setting determines whether a product appears in search results or in the product listing.
However, to see what is set for a product here, you have to open the product page and then click the settings button again.It would be nice to have an option right here in the product overview to filter by visibility settings.
2 votes -
Allow for CMS elements to be hidden on category pages when product listing page is not the first page
When a category layout contains some text or images together with the product listing element, that text or element may be indexed by search engines multiple times for each page of the listing, leading to duplicate indexing and results.
It would be helpful if certain elements could be hidden once the customer or the indexing bot navigates through the listing pages, or a URL contains the ?p= parameter. This would prevent redundant indexing.
2 votes -
payment method per customer
Default payment method should be available per customer so that we can use this information for
- customer account
- Reports
- order confirmation2 votes -
Product visibility: Only when customer has specific prices
There have been a few requests by B2B shop owners where the challenge is as follows:
Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.
From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.
After that was all negotiated, I'd get a price list for the various categories with individual prices, bonuses, conditions and so forth and the supplier would set it up on their end so that I could place orders online (if I wanted to) in their shop. Strictly speaking, I'd find all/most of the other items in their shop as well, but I would have preferred if I didn't - so my line of thinking aligns with the requests we got about this in Support, because I already negotiated every item which was relevant to the company I represented ahead of time - I don't need and don't want to see things I had no interest in and likely have no price list for either.
So - two birds with one stone:
1) The observer sees all the items they have a specific price for
2) The observer does not need to filter what is/was relevant to themThe implementation screams B2B Components. But I think the implementation is potentially simpler if done via Dynamic Access:
If we had a condition which checks whether or not the observer has custom prices of any sort (be it via customer group - this should be the first condition in my mind - extended prices OR customer specific prices, we'd have all the rest covered already.
There have been a few requests by B2B shop owners where the challenge is as follows:
Products should only be visible IF the observer/customer has specific prices for them. Basically, this means that no products are visible UNLESS the customer has a set price for it.
From the perspective of a former B2B procurement manager: This is a relatively common thing to see. I purchased tools for the manufacturing personnel, for example. I'd contact the potential suppliers once a year, we'd sit down, talk projected order volumes, figures and conditions.
After that was all negotiated, I'd get a price list…
3 votes -
Increase value for "items per page" on customer > addresses (make it configurable)
Increase value for "items per page" on customer > addresses:
- Add values "250" and "500"
- Make default value for "items per Page" configurable so it can be set to <>25
2 votes -
Easier customization of email templates
Customizing email templates is usually quite complex and hardly feasible for the average customer. For example, adding the manufacturer's name for each item in the order confirmation.
The entire process of customizing email templates should be significantly simplified and made much more intuitive. We also receive a large number of support requests regarding this.
2 votes -
Payment method change after order receipt with new payment method
Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.
Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.
This results in the following scenarios not being handled correctly:
- Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
- Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
- Changes to customer data, addresses, or order items are not reflected.This means that customers cannot select an updated payment method, even if they meet the requirements after placing the order.
The payment method cannot currently be changed in the admin panel either.
When changing the payment method for an existing order, the payment methods should be determined dynamically based on current data and rules – not based on historical data.
The customer should therefore always see all currently valid payment methods.
Currently, when changing the payment method of an existing order (/account/order/edit-payment), the rule engine is not re-executed.
Instead, Shopware continues to use the payment methods that were available at the time the original order was placed.
This results in the following scenarios not being handled correctly:
- Payment methods become valid for the customer retroactively (e.g., based on tags, customer groups, or rules) → but do not appear in the selection.
- Rules change retroactively (e.g., "Always valid" is added) → no update occurs.
- Changes to customer data, addresses, or order items are not reflected.This means that customers…
5 votes -
B2B Components: add CSV bulk import of Employees and Addresses
Some customers may receive the request from business partners to create a lot of employee account with different addresses (see for example support case #SWAG-322222).
Currently each employee and address would need to be added by hand or via the API. Bulk importing as a CSV would make this a lot easier.
3 votes -
AI: Productstreams / Crossselling
Little has happened since the introduction of AI.
The use of AI to generate customer-specific product streams for cross-selling would be indispensable and a major step forward. For example, based on order history. This is very important for the customer.
Cross-selling is currently very rigid. AI could be used to analyze the customer's order and then make specific suggestions. This would be a huge step and benefit for customers and a game changer.
15 votes -
Add more granular permissions for PayPal
Currently, every admin user with the permission to edit an order (order.editor) can issue refunds of PayPal payments. It would be very helpful to add more granular permissions so that employees can modify orders but cannot issue refunds.
4 votes -
Quick check for plugin and dependency updates compatible with current Shopware version
Right now, there’s no quick way to see which plugin or dependency updates are actually compatible with the installed Shopware version.
composer outdated shows all new versions, ignoring compatibility.
The Admin popup just says “updates available” without details.
It would be very helpful to have a CLI command and/or an Admin view that lists only installable updates based on the current Shopware version.
7 votes -
Extended Product Visibility Control - Separate Search Settings
Enhance visibility control options for products in product listing and search listing.
Per product visibility setting, the following options are currently available:
Visible (All)
Hide in product listings
Hide in product listings and searchWith the current logic, it is only possible to:
Hide a product from listings, or
Hide it from both listings and search.However, it is not possible to keep a product visible in listings (e.g., categories, sliders, cross-sellings) while hiding it only from search results.
Requested Enhancement
Introduce an additional visibility option:
Visible in listings but hidden in search
This would allow merchants to control product discoverability more precisely without removing products from structured browsing contexts. Greater flexibility for B2B and enterprise use cases.
Enhance visibility control options for products in product listing and search listing.
Per product visibility setting, the following options are currently available:
Visible (All)
Hide in product listings
Hide in product listings and searchWith the current logic, it is only possible to:
Hide a product from listings, or
Hide it from both listings and search.However, it is not possible to keep a product visible in listings (e.g., categories, sliders, cross-sellings) while hiding it only from search results.
Requested Enhancement
Introduce an additional visibility option:
Visible in listings but hidden in search
This would allow merchants to control product…
2 votes -
Feedback regarding voucher/promotion response in the shopping cart
Topic: Missing User Feedback for Unactivated Coupon Promotions
Description:
When a customer enters a coupon code linked to a promotion during checkout, it is technically validated.If the promotion cannot be activated due to the current contents of the shopping cart (e.g., due to product category or discount restrictions), the customer receives no feedback on the front end.
From the customer's perspective, nothing happens – even though the code would be valid.
Current Behavior (Default):
- Coupon is checked in the background.
- No error message or information is displayed if conditions are not met.
- The customer does not know whether the code is invalid or if there are simply no matching items in the shopping cart at the moment.Expected Behavior / Improvement Suggestion:
- Display of feedback such as:
"The coupon has been accepted, but there are currently no matching items in the shopping cart."
- Alternatively: A generic message stating that the coupon will be activated as soon as matching items are added to the shopping cart.Rationale:
- Increases transparency and customer trust.
- Avoids frustration caused by seemingly "non-functional" coupons.
- Improves user experience without impacting existing promotion logic.Suggested implementation:
- Add an informational message to the frontend (e.g., in the sw-promotion-code-form or via AddCodeError/AddCodeSuccess handling).
- Alternatively: A backend event hook that checks promotions and provides a flag or message object.Topic: Missing User Feedback for Unactivated Coupon Promotions
Description:
When a customer enters a coupon code linked to a promotion during checkout, it is technically validated.If the promotion cannot be activated due to the current contents of the shopping cart (e.g., due to product category or discount restrictions), the customer receives no feedback on the front end.
From the customer's perspective, nothing happens – even though the code would be valid.
Current Behavior (Default):
- Coupon is checked in the background.
- No error message or information is displayed if conditions are not met.
- The customer does not…5 votes -
Admin orders: Add option to manually add deactivated products
A customer of ours suggested this feature;
It should be possible to have the option to add deactivated products to a manually placed order. Perhaps with a checkbox while we're adding the products or clearly mark the deactivated products in order to avoid mixing them up with active ones, in case product names are rather similar.
The specific usecase is this:
That merchant frequently places manual orders in their Admin for customers. Contrary to what one might assume (I did so as well), it is not a once-in-a-lifetime event that while you work on said manual order, another customer in the frontend already buys the stock away, leading to the product no longer being available. The shop owner reported THREE separate occasions where this happened and thus, understandably, now seeks a solution for these cases.
There are workarounds of course, but they all come with advantages and disadvantages and at least I was not able to think of any which is really failure proof. They all also require multiple steps to get them working (like manually adjusting stock amounts before the manual order and then after again) other than automating everything via API, which sort of defeats the point of Admin orders.
Assuming we tackle this problem, it should most definitely be a setting or option because if we show any and all products, even deactivated ones, as possible selection during the creation of manual orders, we'll probably introduce new problems for shops which only have products available once and never again afterwards. In these cases, the products likely end up disabled once they're sold out and they'd NOT want those to clutter the dropdown list when placing an Admin order.
A customer of ours suggested this feature;
It should be possible to have the option to add deactivated products to a manually placed order. Perhaps with a checkbox while we're adding the products or clearly mark the deactivated products in order to avoid mixing them up with active ones, in case product names are rather similar.
The specific usecase is this:
That merchant frequently places manual orders in their Admin for customers. Contrary to what one might assume (I did so as well), it is not a once-in-a-lifetime event that while you work on said manual order, another customer in…
2 votes -
Toggle for readonly custom-fields
It would be nice to have a toggle for custom fields to mark them readonly (at least in the UI).
We often have the case that custom field values are imported from other systems (like a PIM) and should not be modified through the Shopware Admin UI. But it's nontheless nice to see their values there.
So it would be a really nice option to be able to mark them as readonly.1 vote -
Make the display of search suggestions configurable in the backend
When searching for customers in the backend, the first name and surname are displayed first, which is not ideal for B2B customers. In this case, it would be better to display the company name.
We would therefore like an option that allows us to choose which piece of information is displayed first in the search suggestion. The screenshot illustrates the relevant section in the backend.
1 vote
- Don't see your idea?