What is the motivation for adding/enhancing this feature?

Improving the project code quality and prevent regression over time

What are the acceptance criteria

• codacy scan added to PR checks
• codacy status in README.md

Can you complete this feature request by yourself?

No, I believe the Repo Owner should take care of this one.

Additional information

There are ~180 issues that should be addressed. We should plan how to handle it.

What is the motivation for adding / enhancing this feature?

Reviews can already be imported into the vue-storefront-api and are visible in the frontend on product detail pages.
Most users are probably more used to seeing 'star' reviews. In Magento this feature is implemented with ratings.
You can create multiple ratings, which can be active or inactive and assigned to stores.
When creating a new review you can then add ratings between 0 and 5 stars.

At first I thought it's enough to import only the summarized rating value into vue-storefront-api, but since you can also create reviews, it might be necessary to add ratings as an entity.
The rating votes should be then added to a review.

What are the acceptance criteria

• Users can see ratings for products
• Users can create new reviews with ratings

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

Current behavior

Switching from Favorite to PDP on the same type of product doesn't change the product

Expected behavior

Clicking on specific product in Favorite should direct on page of this product

Steps to reproduce the issue

1. Open any PDP
2. Add product to Favorite (click on Add to favorite)
3. Change color or size (or a both) of product
4. Open Favorite section and click on product added in 2 step.

Environment details

https://test.storefrontcloud.io

Additional information

When user refresh the page then product reload on properly

Why I cannot use Node v12? Minimum version – ok, I understand. But what a problem with maximum version?

• Put only config options that are mandatory in local config, document others,
• Lower the number of config options required for the user

What is the motivation for adding / enhancing this feature?

Because of it's nature the serverPull synchronization method can cause some UI malfunction when the results from Magento/other backend came too late. I mean - when pulling the cart takes 10-15s the user can in the meantime modify the shopping cart and in the result she or he can be really scared when some items were removed added .. wow this is crazy :)

We should count the time between serverPull and serverAfterPulled actions. When it's longer than specific threshold we should switch the further shopping cart synchronization off (we can alter the rootStore.state.config.cart.synchronize=false and rootStore.state.config.cart.synchronize_totals=false)

What are the acceptance criteria

• the shopping cart synchronization is switched off when backend responds too slowly
• the message (like offline message) is displayed informing user that something went wrong with the backend - but he or she can still use the app

Relates to:

vuestorefront/vue-storefront#2905

What is the motivation for adding / enhancing this feature?

We discussed with patzick that it shouldn't be that I have information "No available product variants" but some variants of this product are available in magento.

What are the acceptance criteria

Make synchronization for Product page in the background (same as on the category page)

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

What is the motivation for adding / enhancing this feature?

If you set a basic auth on API, there is no way to connect to it from SSR VSF.

What are the acceptance criteria

• it's possible to connect to basic auth protected API

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

What is the motivation for adding / enhancing this feature?

We're using the product.product_option to provide the backend with the selected product options. Here you have the code which is setting the options right now.

Let's simplify it from:

{  
   "cartItem":{  
      "sku":"WS05",
      "qty":1,
      "product_option":{  
         "extension_attributes":{  
            "custom_options":[  

            ],
            "configurable_item_options":[  
               {  
                  "option_id":"93",
                  "option_value":"56"
               },
               {  
                  "option_id":"142",
                  "option_value":"167"
               }
            ],
            "bundle_options":[  

            ]
         }
      },
      "quoteId":"587011"
   }
}

TO

{  
   "cartItem":{  
      "sku":"WS05",
      "qty":1,
      "option":{  
            "custom":[  

            ],
            "configurable":[  
               {  
                  "option_id":"93",
                  "option_value":"56"
               },
               {  
                  "option_id":"142",
                  "option_value":"167"
               }
            ],
            "bundle":[  

            ]
      },
      "quoteId":"587011"
   }
}

Current behavior

The buttons are not clickable on Internet Explorer like the login button, cart button and add to cart button.
Also the add to cart does not work.

Furthermore the images are not loaded.

This has been tested on Internet Explorer 11 on https://demo.storefrontcloud.io and confirmed on our own testing enviroment.

Expected behavior

We suspect it has something to do with local caching and Service workers. It should always have a fallback for browser that do not support that.

We also can not find a compatibility list but found another issue that stated 'We support all major browsers'. Not sure if IE is still in that list.

Steps to reproduce the issue

Open Internet Explorer 11

1. Surf to https://demo.storefrontcloud.io
2. Go to a product --> see placeholder images
3. Try to open menu, add a product or login --> buttons not working

Can you handle fixing this bug by yourself?

• [X ] YES
• NO

But with no time limit. We are building a Vuestorefront project for one of our customers and frontend development will occur after the API connection is implemented.

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• [ X] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

• Browser: Internet Explorer 11
• OS: Windows 10
• Node: NA
• Code Version: NA

I had problem with css rendering. Here I use vue-boostrap but after Vue-Storefront render complete my boostrap button will got override by Vue-Storefront css ?!
So how can I install it properly with external vue-component or css framework ?
How I can install external component properly do you guy have any advice because this is very important to many people.

What is the motivation for adding / enhancing this feature?

The application architecture is very good, but also very advanced. Someone new to the project may not easily be able to set up debugging a Node.js process inside a docker container trivially. Plus every new person coming in has to do this probably at some point, so why re-invent the wheel?

Since VS code is already the recommended IDE, a possibility is to commit a dev's .vscode folder. If committed as is, it would change someone's tailored setup (not good!). So instead, we could commit either as .vscode-default folder or rename each file w/ a .default suffix (launch.default.json) -- which is inline w/ the config folder setup process.

Can you complete this feature request by yourself?

NO (I'm one on the new devs struggling w/ this!)

Summary

[summary]: We need to refactor the Checkout page to be more flexible, easy to extend and get rid of the current way of adding payment/shipping modules which are solely based on the Event Bus (#3020)

This is the open request for proposals/feedback on how the best possible Checkout feature should work like from the developers perspective.

Motivation

[motivation]: We're moving towards https://storefrontui.io to be used in the themes. Current checkout is pretty messy, based on events - hard to extend and to event understand to be the new-comers. The idea is to make the payment/shipping modules less error prone plus increase the extensibility (adding/removing/changing) of the checkout steps.

Guide-level explanation

It would be great to focus on the following features of the checkout with the proposals - on which we'll form the final design for the Checkout feature:

1. How to hook-in into checkout process - currently there are events like https://github.com/danrcoull/vsf-payment-braintree/blob/d42a2e6f2ccc227aad6c183ea8c089da032a73cb/hooks/beforeRegistration.ts#L25 that modules hook in. How should it be handled?
2. How to override the Checkout components? Should it be kind of API like dispatch('checkout/addStep'),dispatch('checkout/removeStep') ... ?
3. How to modify/extend the Checkout UI - especially the payment modules should have an option to hook in and add some forms / inject JS code. For example, the stripe module is expecting us to add the UI manually (probably it's not an optimal way): https://github.com/develodesign/vsf-payment-stripe#integration-the-stripe-component-to-you-theme
4. How to handle the validation? Should we stick to the Vuelidate that we're using currently or switch to another library? How to hook in the validation process for the custom steps?

Happy to hear Your comments / code snippets / requests on this feature./

It seems that ES aggregations (e.g. filter values) are limited to 10 items by default.

This can be reproduced easily in the official demo store with the 'size'-filter. If there are enough products (e.g. Default Category) the filter sidebar never shows all available sizes which are available according to product detail pages.

The solution is an additional configuration object which can be passed to the aggregation config as additional argument within bodybuilder.js - hardcoded it would look like this:

export function baseFilterProductsQuery (parentCategory, filters = []) {
 
      // ...

      searchProductQuery = searchProductQuery.aggregation('terms', attrToFilter, { size: 100 })
      searchProductQuery = searchProductQuery.aggregation('terms', attrToFilter + '_options', { size: 

      // ...

  }

It would be nice to have an additional config entry in config.json to allow dynamic configuration without the need to override core functionality. I'd suggest to use the following structure:

{
    ...

    "elasticsearch": {

        ...

        "filterAggregationConfig": { // placed here because it is an ES-related issue...
            "manufacturer": { size: 100 },
            "size": { size: 50 },
        }
    }

    ...
}

I'm willing to do a PR which passes such config if it exists to the query. Let me know what you think about the approach. Since I'm not very familiar with ES I'm not sure if there would be another possiblity which would allow to override this setting...

Feature Request here moved from vuestorefront/vue-storefront-api#318

What is the motivation for adding / enhancing this feature?

Logging to and fetching data through social media like facebook.

What are the acceptance criteria

• Login with facebook
• Login with google
  can be separate modules + nice layer for implementing additional ones

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

The notifications are to be moved to vuestorefront/libs.

The notifications should be moved to the template as it is presentation logic.
The developer implementing would decide what is shown.

Current behavior

-> When creating an account while placing an order, the validation of the entered password is carried out at the end when attempting to place an order.
-> If user provide too short password (for ex mypass) at first the validation message about password min length is shown.
-> After re-entering longer password, the client must go through all the checkout steps and try to place an order again.
-> Next the validation message containing information about the additional requirements for building the password is shown for a short time - so that the user is not able to read it.
-> After again re-entering a more complex password, the client must go through all the checkout steps again.

Expected behavior

Validation of the password structure should take place as soon as it is entered (so that the customer can correct it right away), and the validation message should be visible until the password requirements are met (so that the client knows what the requirements are).

As a result, the customer does not have to go through the entire shopping path again and again just because he has entered a password that does not meet the standards.

Steps to reproduce the issue

1. Open https://demo.storefrontcloud.io/
2. Add any product to the cart
3. Click 'Go to checkout'
4. Fill in personal details section
5. Check option 'I want to create an account' and provide two identical, not complex and short passwords (for ex 'mypass')
6. Accept Terms and conditions
7. Fill in shipping and payment sections
8. Go to review order
9. Mark checkbox 'I agree to Terms and conditions'
10. Click on 'Place the order' -> the first validation message is shown (password is too short)
11. Go to personal details section and provide longer password (for ex. 'mypassword')
12. Go through all the next steps again
13. Click on 'Place the order' again -> the second validation message is shown (password have to meet a few requirements)
14. Go back to personal details section again
15. Provide more complex password according to the requirements
16. Go through all the next steps again
17. Successfully place the order.

Can you handle fixing this bug by yourself?

• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

• Browser: many
• OS: Windows 10

What is the motivation for adding/enhancing this feature?

Extracting state synchronization to a visual layer and notifying a user about successful/unsuccessful actions when he's back online would simplify and solve a lot of issues regarding offline actions. It should be used in ordering out of stock products, products that have additional business validation, invalid address fields, expired coupons, etc.

What are the acceptance criteria

• When a user gets into offline mode, an additional icon should be shown in the menu. Could be a bell, could be something like:
  ( to be discussed with a UX Specialist)
• When there are queued actions to be synchronized, an icon can be clicked to display a dropdown list with actions to sync and status (to sync, in progress, failure). Should look like more or less like facebook notifications
• Successful actions are removed from the dropdown list
• When there is a failure, the user should see the notification and the icon should be red to indicate that there are some problems to be fixed with a short description of the issue.
• (If applies) a user can click failed action to correct the issue, click "reload" icon to retry or click "X" to remove that action from the list (simply ignore the issue)
• When a user is online and the list is empty, the status icon should disappear.
• Following scenarios are covered:
  • a user is trying to order a product that is out of stock
  • a user is trying to order more products than there are in stock
  • there are issues with checkout details that a user has entered while finishing the order
• the whole mechanism has extension friendly architecture to add additional error handlers in an easy way

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case, the Developer should create a branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

In the future, it could be extended with push notification support if a user has already left the website before sync was fully finished.

A UX desing would be very helpful for this feature :)

it would be really good to have a complete catalog search results page with filters and sorting options

Current behavior

As mentioned in vuestorefront/vue-storefront#3270, in multistore mode the default storeview is unnecessarily being initialized and later changed to target storeview.

The full scenario is as follows:

• Server initializes full default storeview including translations, sync task storage etc in
  https://github.com/DivanteLtd/vue-storefront/blob/c53ccb0073c0810b735df0f944bd20d6fba608d4/core/app.ts#L75
• Server adds to the router every single page for every single storeview defined in the config
• Server's router matches a page with the corresponding storecode
  https://github.com/DivanteLtd/vue-storefront/blob/c53ccb0073c0810b735df0f944bd20d6fba608d4/core/server-entry.ts#L73-L83
• Server initializes full target storeview by storecode from the previous step <-- extend mechanism is here

In addition, appendStoreCode attribute is used in 2nd step, while it's being inherited in the 4th step so it cannot be extended.

Expected behavior

App initialization in multistore mode is rewritten to a way that there is no need to initialize any other storeview than the target one. All storeview attributes should be inherited through the "extend" mechanism, including appendStoreCode and url.

After fixing inheritance of attributes mentioned above, please adjust the docs.

Can you handle fixing this bug by yourself?

• YES but not anytime soon.
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

http://demo-magento2.vuestorefront.io/luma-yoga-for-life.html

What is the motivation for adding / enhancing this feature?

There should be a possibility for targeted local storage flushing. Like after a deployment or rebuild this could be needed to have the current information available at the client side. Right now it is up to the user to do so and that is not really helpful for getting updated stuff out to the browser.
If the user completely throws their local storage we need to take care of not accidentally clearing the cart information.

What are the acceptance criteria

• remove targeted stuff from local storage
• remove everything beside session information

Can you complete this feature request by yourself?

• YES
• UNSURE
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

According to w3c this is intended behavior as the user or the application is responsible for the local storage only. There is no TTL intended, but there are different options we found: https://stackoverflow.com/questions/2326943/when-do-items-in-html5-local-storage-expire but nothing seems "ready to use"

One of the more challenging parts of the checkout has been payment gateways. This RFC is an effort to streamline integrations, offering standardized workflows.

Since integrations like these touch the stack on every level and need tight integration in both the frontend, as well as the underlying e-commerce engine, a clear separation of concerns should be made.
The frontend and middleware should be as agnostic as possible, containing little to no business logic.

This RFC focusses more on the high-level architecture than specific implementation details, although these are welcome of course.

Integration divided into actions

For a generic Payment Gateway, assuming we're dealing with online payments (Credit Card, Sofort, iDeal, etc), the integration can be divided into various actions. Below an overview of the actions with a short introduction into requirements and challenges.

1. Fetching payment methods

Payment methods are to be displayed in the frontend in the Checkout UI. These payment methods might be simple options or have their own UI like a Credit Card asking for card number and name.
The methods to be displayed may vary depending on variables of the order being created; subtotal, billing country or the types of items.

2. Communication with Gateway

The selected payment method, with any user input added, is bundled with order details and send of to the Payment Gateway. Here it's important to note this has to be done encrypted.
Optionally the user might need to be redirected to an external page to finalize the payment.

3. Payment status callback

Once the payment has been processed by the payment gateway a callback is done to the originating platform. This updates the order registering a payment, or a failure.

New proposed integration

The new flow has a clear separation of concerns where business logic is focussed in the underlying e-commerce platform, the middleware merely transforms data and the VueJS app handles presentation.

What is the motivation for adding / enhancing this feature?

During the free time I'll take care of migrating our caching mechanism to Workbox 3. we will cut off some webpack config and make use of newest features

##Relates to:
vuestorefront/vue-storefront#3348

Steps to reproduce the issue

Scenario 1:

1. Log in into vsf
2. Add any products to wishlist
3. Log out
4. Make sure that wishlist is empty now
5. Refresh page

Scenario 2:

1. Log in into vsf
2. Add any products to wishlist
3. Log out
4. Make sure that wishlist is empty now
5. Again add any products to wishlist (as guest)
6. Log in into vsf (use the same account as in step 1)
7. Check Wislist

Current behavior

Scenario 1:
After refreshing the page, products occur again on Wishlist (despite the user being logged out)

Scenario 2:
There are only products added by guest (in step 5). The previously added products (in step 2) are gone.

Expected behavior

If logged in customer add products to the wishlist, the list will be stored in Magento i.e. products within the list will not disappear unless customer removes it manually.

If not-logged in customer add products to the wishlist, the list will be stored in browser cache i.e. products within the list will not disappear unless customer clears the browser cache.

If the customer will add products as a not-logged in and then logged into his account, products added to the wishlist before the login will be merged with products in the stored wishlist.

Repository

Can you handle fixing this bug by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

• Browser:
• OS:
• Node:
• Code Version:

Additional information

What is the motivation for adding/enhancing this feature?

When using a mobile to browse the app, on the product view, it would be easier to purchase an item if the Add to Cart is visible. This way the user won't have to look for the Add to Cart button, it will be accessible.

What are the acceptance criteria

• [ ] Add to cart button pops up from on the bottom of the screen when the user scrolls under the title.

Which Release Cycle state this refers to? Info for the developer.

This is an idea needs design and implementation. It is an easy good first request.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

This is a quick and not detailed mockup

Modules, Service Workers and Server Routes should be able to be extended on both global, as well as theme level.
Currently only global is possible.

Hello,

Love vue storefront a lot and learning how to build my own theme for plugging vs to my magento system.

Would like to know if magento's 'Restock notification' function will be activated in vs later too?

Thanks a lot!

What is the motivation for adding / enhancing this feature?

Some cart actions cause sending many API requests to do simple actions eg. adding or removing products to/from the cart. Sometimes user can see some part of the UI that have not refreshed yet even though he has triggered some changes or sometimes it takes really long. Would be nice to sort out with that.

What are the acceptance criteria

• reduced number of api calls

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

What is the motivation for adding / enhancing this feature?

The user should not be redirected from user state dependent pages to the homepage on both logging in and refreshing the page.

What are the acceptance criteria

• user doesn't get redirected to homepage when he logs in but the page has some user state dependent components
• user doesn't get redirected to the homepage every time he refreshes a page that is user state dependent

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

What is the motivation for adding / enhancing this feature?

Currently the validation message, for providing the email that is not in the database, shows:
“No such entity with email=[email protected], websideID=1”
The content of the message should be more user-friendly.

What are the acceptance criteria

• Change the validation message to “The account for provided email address: [email protected] doesn't exist”

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

What is the motivation for adding / enhancing this feature?

Currently, You must set all available filters in the config.products.defaultFilters. It would be much better to load the list of the filterable attributes based on the search results (attributes of the products returned)

Related to vuestorefront/vue-storefront#1975

As this change may affect the performance (much more attributes to be loaded) - we probably need to add a config option for enabling/disabling this feature

What are the acceptance criteria

• The filter list is generated automatically and all possible attributes used in filters are dynamically loaded without the need to modify the config

What is the motivation for adding / enhancing this feature?

Add the support for Cloudinary for image proxy instead of using the /api/img endpoint.
Related source location: https://github.com/DivanteLtd/vue-storefront/blob/65b964f049f3d100a8523779ca20aa78af6def7f/core/helpers/index.ts#L46

What are the acceptance criteria

• vsf-cloudinary module ready to be installed to VSF :-)

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

What is the motivation for adding / enhancing this feature?

The feature request to add a Recommended products block based on the:
https://cloud.google.com/recommendations-ai/docs/

What are the acceptance criteria

• RecommendedProducts smart commponent added to display the recommended products
• vue-storefront-api based product catalog integration with the Google API (to send out the catalog data)
• Vue Storefront integration - calling out Google APIs with what users are browsing, adding to the cart etc.

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

• removing unnecessary loaders
• minimize the scope of loaders

https://webpack.js.org/guides/build-performance/

We need to map the standard Magento2 feature of Giftcards to Vue Storefront checkout
In the second step, we should add the ability for the user to buy Gift card as a virtual product

What is the motivation for adding / enhancing this feature?

By each product or category page request we're currently executing at least few requests for Elastic data:

• get product,
• get related,
• get reviews,
• get attributes

How about merging them all into a single request? It could be very easily done at the syncData method level.

I mean if we take all the requests directed to Elastic and merge them into a single one;

instead of:

query no 1: Product

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"visibility":[2,3,4]}},{"terms":{"status":[0,1]}},{"terms":{"category_ids":[20,21,23,24,25,26,22,27,28]}}]}}}},"aggs":{"agg_terms_color":{"terms":{"field":"color","size":10}},"agg_terms_color_options":{"terms":{"field":"color_options","size":10}},"agg_terms_size":{"terms":{"field":"size","size":10}},"agg_terms_size_options":{"terms":{"field":"size_options","size":10}},"agg_terms_price":{"terms":{"field":"price"}},"agg_range_price":{"range":{"field":"price","ranges":[{"from":0,"to":50},{"from":50,"to":100},{"from":100,"to":150},{"from":150}]}},"agg_terms_erin_recommends":{"terms":{"field":"erin_recommends","size":10}},"agg_terms_erin_recommends_options":{"terms":{"field":"erin_recommends_options","size":10}}}}

query no 2: Attributes

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"attribute_code":["pattern","eco_collection","climate","style_general","performance_fabric","material"]}},{"terms":{"is_user_defined":[true]}},{"terms":{"is_visible":[true]}}]}}}}}

query no 3: Breadcrumbs

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"id":[2,35,30,23]}},{"terms":{"is_active":[true]}}]}}}}}

query no 4: Reviews

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"product_id":[1385]}},{"terms":{"review_status":[1]}}]}}}}}

query no 5: Related products

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"category_ids":[2,35,30,23]}},{"terms":{"visibility":[2,3,4]}},{"terms":{"status":[1]}}]}}}}}

query no 6: Upsell products

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"category_ids":[2,35,30,23]}},{"terms":{"visibility":[2,3,4]}},{"terms":{"status":[1]}}]}}}}}

Have single request:
query no 1: Combined query

[
{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"visibility":[2,3,4]}},{"terms":{"status":[0,1]}},{"terms":{"category_ids":[20,21,23,24,25,26,22,27,28]}}]}}}},"aggs":{"agg_terms_color":{"terms":{"field":"color","size":10}},"agg_terms_color_options":{"terms":{"field":"color_options","size":10}},"agg_terms_size":{"terms":{"field":"size","size":10}},"agg_terms_size_options":{"terms":{"field":"size_options","size":10}},"agg_terms_price":{"terms":{"field":"price"}},"agg_range_price":{"range":{"field":"price","ranges":[{"from":0,"to":50},{"from":50,"to":100},{"from":100,"to":150},{"from":150}]}},"agg_terms_erin_recommends":{"terms":{"field":"erin_recommends","size":10}},"agg_terms_erin_recommends_options":{"terms":{"field":"erin_recommends_options","size":10}}}},

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"attribute_code":["pattern","eco_collection","climate","style_general","performance_fabric","material"]}},{"terms":{"is_user_defined":[true]}},{"terms":{"is_visible":[true]}}]}}}}},

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"id":[2,35,30,23]}},{"terms":{"is_active":[true]}}]}}}}},

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"product_id":[1385]}},{"terms":{"review_status":[1]}}]}}}}},

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"category_ids":[2,35,30,23]}},{"terms":{"visibility":[2,3,4]}},{"terms":{"status":[1]}}]}}}}},

{"query":{"bool":{"filter":{"bool":{"must":[{"terms":{"category_ids":[2,35,30,23]}},{"terms":{"visibility":[2,3,4]}},{"terms":{"status":[1]}}]}}}}}
]

Challenges:

• concurrency - parallel queries - not all queries can be pooled into single request as some of them are results of another one :)
• currently, most of their users are using the GET method for Elastic requests in order of having easier output caching and service workers doing its job. We need to cover this scenario as well and it could be challenging as the GET method will get a really huge one if you combine few requests into one
• to check if Service Workers do properly cache POST methods - if so then this is not a big deal

In order to have this feature work we need to extend vue-storefront-api for kind of graphql-like resolvers handling the queries (which would be extremly simple as the queries in the end are just ES queries)

Summary

Add a hyperlink to the user and PR. To have them when you open the changelog.md

Motivation

This would be grade to have so when you clone the repository or open the changelog file directly you can go the the PR and not need to search it or go the the releases page.

One why this could be done without having long lines is to use a reference-style link.

What is the motivation for adding / enhancing this feature?

As we're using PM2 for production process management it would be nice to add the KeyMetrics integration for key metrices:

• SSR rendering time,
• API response times,
• API availability,
• ElasticSearch availability + response times
• other metrices for monitoring the SLA

What are the acceptance criteria

• The specified list of metrices monitored in KeyMetrics

Can you complete this feature request by yourself?

What is the motivation for adding / enhancing this feature?

1. User add items that regularly purchases to a wishlist/favourites. When they want to reorder items from wishlist, they are able to add products directly from the wishlist into the cart without the need to go into each products individual page. This provides a quicker user journey for customers that are regularly purchasing the same items.
2. Users can go into a category listing. Users can add products to the cart from the product tile without having to go into each individual product page.

What are the acceptance criteria

• User can see a quantity and add button for each product in their wishlist.
• When clicking the add button, the desired quantity of that product is added to the cart.
• User can see a quantity and add button under each product tile.
• When clicking the add button, the desired quantity of that product is added to the cart.

Can you complete this feature request by yourself?

No

Additional information

The tesco tiles for example:

Current behavior

I have Magento Configurable Product which also has Custom Options on the parent. This works fine in Magento, but in VSF even though the custom options are displayed the attribute selection of the child products dissappear since product.errors is populated with { "custom_options": null, "custom_options_customOption_XX": null }.

Expected behavior

Magento-like behaviour where one can have both working Custom Options on Configurable Products.

Steps to reproduce the issue

1. Add custom options to Configurable Product in Magento

Additional information

I don't know wether this is a bug/misconfiguration or this setup is generelly not supported by VSF. Please mark as Feature Request if the latter.

• Make a test dir in theme for e2e
• Make unit tests work from theme with extension point

What is the motivation for adding / enhancing this feature?

Currently vue-storefront-api is accessing ElasticSearch just in read-only mode. The src/api/catalog.js is not accepting any other endpoints than _search. This is good approach regarding the security, however with new magento2-vsbridge-indexer and magento1-vsbrdige-indexer users must connect these modules directly to Elastic without the vs-api in the middle. It won't work with cloud deployments (like storefrontcloud.io) where there is no public access to Elasticsearch instance.

We should extend the catalog.js:

• add htaccess authorization over ElasticSearch
• add the following endpoints:
• bulk
• create
• refresh
• exists
• delete
• putMapping
• deleteByQuery

Details: https://github.com/DivanteLtd/magento2-vsbridge-indexer/blob/master/src/module-vsbridge-indexer-core/Elasticsearch/Client.php

What are the acceptance criteria

• native indexer could be connected to vue-storefront-api
• authorization works

What is the motivation for adding / enhancing this feature?

Currently, 'My orders' displays orders, which are assigned to a given email address and not to a user account.
As a result, we always see all orders made from this email address and not only those placed from the account created for this email address.

Situations where this may be a problem:

1. After removing the user account (from the magento level) and re-creating it by the user, the 'My orders' tab will display old orders for the previous account.
2. Similarly, when I place orders without creating an account for a given email address, later when I set up an account, in 'My Orders' I will see orders that I made without creating an account.

Due to the fact that setting up an account does not require any confirmation - anyone can set up an account for my email and see all orders I have previously made.

But it can also be useful:

1. If creating an account requires confirmation - after setting up an account for my email, I can see the whole history of orders placed before creating an account.

So we should add the option of setting in the config how we want to display orders:

• for email address
• for the user's account.
  If there will be an additional authorization for creating an account, we can safely use the first option.

Related problem: An order during which a new customer account is created is not assigned to this account

If I create a new account while placing an order - this order is not assigned to the created account. In Magneto, the new user has no orders and the new order is visible as made by Guest. In My orders, a new order is visible only because all orders for the email are currently displayed, not for the user account.

From the user point of view, I create the order in parallel with the creation of an account, so this order should already be saved as placed by the client with the account and not as submitted by the Guest.

What are the acceptance criteria

• In config, you can set how orders should be displayed (for email address / for a user account).
• After choosing the option of displaying orders for the email address: in the 'My orders' tab, all orders placed to the email address for which the account was created are visible.
• After choosing the option of displaying orders for the customer's account: in the 'My orders' tab, all orders placed after logging in to this account are visible.
• After creating an account while placing an order, I can see in "My orders" first order that I made (regardless of the setting selected in the config for displaying orders). This order has displayed my account details in the 'Author' section.

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

To facilitate easier integration with a wide range of backends the data models that are at the basis of what we build should be generic.
Entities such as products, categories, customers and orders should be simplified and stripped of any logic tied directly to Magento. At the basis is an agnostic model which can be extended, or used, by another model specifically handling Magento or Shopware or another platforms logic.

For this, we'll create Domain Objects describing in generic, unambiguous terms what properties an object can have and what basic behaviours it should offer, from there we expand for each integration that is done the specifics for the underlying backend.

Current behavior

Vue-offline is outdated and doesn't have webpack and babel in version 1.0.8. This behavior brakes code on IE, with unreadable syntax like arrow functions and const.

Expected behavior

We should update this lib to newer version, and add support for IE11+

Steps to reproduce the issue

Just open demo.storefrontcloud.io on IE11+

Can you handle fixing this bug by yourself?

Yes

What is the motivation for adding / enhancing this feature?

Currently, per each catalog request, we're executing at least 2 Elastic queries:

• getting the products,
• getting the tax rates to calc the taxes.

The rates can be stored in Redis/local memory as they're changing extremely rarely!

Where to start:

• https://github.com/DivanteLtd/vue-storefront-api/blob/d7b6fe516eeb214615f54726fb382e72ff2cc34b/src/platform/magento2/tax.js#L80
• https://github.com/DivanteLtd/vue-storefront-api/blob/d7b6fe516eeb214615f54726fb382e72ff2cc34b/src/platform/magento1/tax.js#L80

Related to: vuestorefront/vue-storefront#3367

What are the acceptance criteria

• tax rates are being stored in the local cache and each api/catalog request engages Elastic just for single query

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Additional information

What is the motivation for adding / enhancing this feature?

Currently the configs are kept in one big file, which may quickly increase in size, resulting in hard to read huge config chunk.

What are the acceptance criteria

Keep module config files per module for better separation. The architectural design is up to vue storefront team.

Can you complete this feature request by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a normal feature request. This should be available on https://test.storefrontcloud.io and then after tests this can be added to next Vue Storefront version. In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• (Pick this option only if you're sure) This is an important improvement request for current Release Candidate version on https://next.storefrontcloud.io and should be placed in next RC version. In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• (Pick this option only if you're sure) This is a critical improvement request for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version. In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.