- or
No existing idea results
- ~ No ideas found ~
1434 results found
-
Query data from Shopware Analytics
It would be good if the data from Shopware Analytics could be accessed via the API in order to integrate it into Grafana, for example.
1 vote -
Customer Repository and Context:SKIP_TRIGGER_FLOW by default
The idea is to modify the injected context to the customer repository by SKIPTRIGGERFLOW.
During the creation of the integration plugin with any system in the customer synchronization process, we always have to remember to add Context:SKIPTRIGGERFLOW otherwise a lot of emails are sent to the imported customers.1 vote -
Searchable comments
Customers can add comments on the checkout page
Issue is that in the Administration, it is until now not possible to search for comments of customers
Example:
- customer calls the shop owner and asks if the comment made was considered
- customer wants something excluded or special made10 votes -
Admin Search: Search for content for custom fields
Search for custom fields, which are assigned/available in admin panel e.g. in orders or customers. The simplest thing would be to extend the search range so that the custom fields can also be searched. The AI Cockpit can already do this, it just needs to be extended to the search. Usage e.g. for Authorities, distributors, public offices or organizations that use internal order numbers and refers only to this numbers. Data that is fed into the custom fields in reverse from external merchandise management systems, etc.
18 votes -
'From' price of variants
When productvariants have different prices, the 'from' field is shown on the listing page, only if the price of the main product < price of the cheapest variant. This policy causes a problem:
Suppose two products with variants:
All variants have same price
Prices of variants differ
Assume the products are imported (product feed) from external sources (as we do).
When the price of the main product is set to 0, 'from' is shown in the listing page (before the price; e.g. From € 10,00) for all products with variants. That's not correct: it should only be shown in case 2 above, as in case 1 there is no 'from' as all variants have same price.
When the price of the main product is equal (or higher) to the price of the cheapest variant, 'from' is no longer shown on the listing page. This is (of course) correct in case 1, but not in case 2.
Using product data feeds (e.g. using Channable), it's not possible to create rules that compare prices between several rows (1 row is one variant), so it's not possible to check if a product has variants with different prices (in that case the main product price can be set to 0, when all variants of a product have same price, the price of the main product is same as variant price: in that case 'from' should always be shown/be absent correctly). This means product feeds can't be automated and every product with variants has to be checked (and corrected) after importing.
How to solve?
Suggestions: I think the policy that 'from' is only shown when the main product price is lower than the cheapest variant price should be changed to the main product price is lower or equal to the cheapest variant price.
Or: just check if variants of a product differ in price and if so, 'from' is shown in listing followed by the lowest variant price.
I don't understand why the policy is that the main product price must be lower than the cheapest variant price to trigger 'from' is shown in listings (so, please explain why this is the actual policy).
Is my suggestions are not feasible, how to achieve the correct behaviour (I even doubt if it's against (international) laws, 'from' is not shown when it should be, as to some extend it's misleading customers on listing pages)?
Another related problem:
In the admin product overview, only the main products are shown. To achieve 'from' is shown in the frontend, the main product price must differ from the lowest variant price. Consequently, the price displayed in the admin product list can never be the lowest product (variant) price.
Setting the main product price in case of unequal variant prices to 0 by default means filtering on price in the admin becomes useless (those products all have price 0). At least not elegant.When productvariants have different prices, the 'from' field is shown on the listing page, only if the price of the main product < price of the cheapest variant. This policy causes a problem:
Suppose two products with variants:
All variants have same price
Prices of variants differ
Assume the products are imported (product feed) from external sources (as we do).
When the price of the main product is set to 0, 'from' is shown in the listing page (before the price; e.g. From € 10,00) for all products with variants. That's not correct: it should only be shown in case…
3 votes -
custom products -Surcharge is not displayed
When working with a surcharge and a rule, the base price is still always displayed in the frontend. It would be nicer if the pricing rule were triggered as soon as the "Start Configuration" button is clicked, so that the correct price is displayed. The calculation in the shopping cart is then correct again, it's just the display that is not.
6 votes -
Order statistics in the customer account
We have received feedback from our customers that comprehensive order statistics would be helpful. When logged into the customer account, the following key figures for the customer account should be visible:
Total value of orders
Number of orders
Number of order items
Average order value per order
Average number of order items per order
Items sorted by order total (SKU, item name, order total)5 votes -
Position related discounts in cart / order details
Enable position related discounts in cart and order details. Currently all discounts that have been granted for one cart are beeing summed up and they show as one dedicated position.
7 votes -
It would be great if information on the height, width, length and weight of the product could also be created automatically under "Propertie
It would be great if information on the height, width, length and weight of the product could also be created automatically under "Properties".
4 votes -
B2B checkout: Order reference and deliverydate
SW6 B2B Component should have same functionality as the previous B2B-suite. In Order process (checkout) merchants should have form-fields for own Order-Reference and wishes for the delivery-date.
(order.customFields.b2bOrderReferenceHolder, order.customFields.b2bDeliveryDateHolder)
5 votes -
Ability to disable/hide Customer account menu items
As not everything is offered to customers, it should be easily possible to hide some menu items in the customer account.
For example, most shops won't sell subscription, so it would make no sense to have this menu item. Or if you don't offer different payment methods etc.It would be the greatest if you could hide menu items via the Rule builder, to make it more dynamic based on certain conditions. Example if you de sell subscription, to show the menu item if a customer has a subscritption. And so on.
1 vote -
customer satisfaction survey: Popup after checkout to Shopping experience (NPS, CES, CSAT)
For customer satisfaction survey: ability to ask some simple questions after the checkout to link a shopping experience or survey to external service to measure NPS, CES, CSAT.
3 votes -
Extend rate limit to storefront operations optionally
We can protect most "vulnerable" parts of the store already with a rate limiter. This includes the contact form or login & password reset pages for both the frontend and the Admin.
However, there are "vulnerable" parts for the cart (and potentially other parts) as well. A shop owner monitored that presumably a bot rapidly added products to a cart over and over again over hours, placing high load on the database due to the spam collecting in the cart table.
Since we already have a rate limiter in the code, it would be nice and possibly fairly simple to include other areas of the store to optionally apply the rate limiter here as well.
We can protect most "vulnerable" parts of the store already with a rate limiter. This includes the contact form or login & password reset pages for both the frontend and the Admin.
However, there are "vulnerable" parts for the cart (and potentially other parts) as well. A shop owner monitored that presumably a bot rapidly added products to a cart over and over again over hours, placing high load on the database due to the spam collecting in the cart table.
Since we already have a rate limiter in the code, it would be nice and possibly fairly simple to…
2 votes -
Dynamic urls for flow builder webhooks
It should also be possible to insert variables in the URLs to be called up in the webhooks in order to assemble them dynamically. Many interfaces require this, e.g. for DELETE requests. Example: DELETE https://example.com/api/v1/users/test@example.com
This example cannot currently be implemented, which is a major problem when using the function.1 vote -
B2B: Customer specific rebates
It is possible right now to manage customer specific prices. Several businesses are working the other way round and using the MSRP together with a customer specific rebate. As this data already sits in the ERP systems, it should also be usable in the Shopware B2B components.
1 vote -
Show detailed discounts in the cart overview
When using the quote management function in the B2B components, as the one asking for the offer I want to see what type of discount has been given.
Right now, you can only see the substracted discount but not if it is a total discount in € or a percentage discount.1 vote -
You should also be able to open your own custom forms in the modal.
Custom forms are an element of an experience world and can therefore only be used as part of a category. However, it should be possible to display them in the modal like the standard contact form.
1 vote -
It should be possible to prevent customers without a Paypal account from buying something via Paypal.
If you enter an email address in the Paypal login window that is not registered with Paypal, you can still be paid via Paypal by direct debit. It should be possible to prevent this.
1 vote -
Calculation of shipping costs for panels
I need a shipping condition. In Shopware I can choose between certain shopping cart properties (number of products, shopping cart value, shopping cart volume or shopping cart weight) or a rule from the rule builder. Using the rules from the rule builder, I can then, for example, go and say: If at least one of the products in the shopping cart is longer than 3m (whether it says metres or millimetres is not the issue here) and the weight is less than 30 kg, charge €10 shipping costs, if it is less than 50 kg, charge €20 shipping costs, etc. and then do the same again with 4m, 2m, 6m. Apart from the fact that I can only refer to one of the products at a time (I cannot use the rule builder to query the total length of all items in the shopping cart), it is not possible to use the area instead of the length in this price matrix.
This should be possible!
I need a shipping condition. In Shopware I can choose between certain shopping cart properties (number of products, shopping cart value, shopping cart volume or shopping cart weight) or a rule from the rule builder. Using the rules from the rule builder, I can then, for example, go and say: If at least one of the products in the shopping cart is longer than 3m (whether it says metres or millimetres is not the issue here) and the weight is less than 30 kg, charge €10 shipping costs, if it is less than 50 kg, charge €20 shipping costs, etc.…
2 votes -
Improvement of the function: page layout settings in Categories
Currently, there are three ways to activate the Erlebniswelten design in the shop:
Through the CMS editor, where you can assign the layout to a category.
Directly in the category, under the "Layout" tab.
In the "General" tab of the category, using the "Configure homepage" button in the navigation section.
In my opinion, these options are confusing as they can override each other. Specifically, the "Configure homepage" button overwrites settings from both the CMS editor and the "Layout" tab, which can lead to changes not being reflected in the frontend if the original configuration in that button is forgotten.
It would be ideal to have only one way to configure the layout or to ensure that settings don't overwrite each other but apply globally. The current setup, with multiple configuration options in the backend, is not particularly user-friendly from a UX perspective.
Currently, there are three ways to activate the Erlebniswelten design in the shop:
Through the CMS editor, where you can assign the layout to a category.
Directly in the category, under the "Layout" tab.
In the "General" tab of the category, using the "Configure homepage" button in the navigation section.
In my opinion, these options are confusing as they can override each other. Specifically, the "Configure homepage" button overwrites settings from both the CMS editor and the "Layout" tab, which can lead to changes not being reflected in the frontend if the original configuration in that button is forgotten.
It…
2 votes
- Don't see your idea?