test issue for accepting cla

For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.

The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.

Make sure not to redo what was already done with the big happy path that stan did, but here are some E2E cart ideas.

• Changing quantities updates all cart calculations to a predicted total, with expected effect on promotions as well.
  ** Example: ootb promotion is $20 off if over $200. Increasing product quantity before tax over $200 means the promotion is applied; decreasing product quantity below $200 means the promotion is removed (but appears as potential promotion).
• Clicking remove removes the item from the cart, and same rules for quantity changes apply for calculations and promotions.
• When all items are removed from cart, the page states there are no items, and you can't go to checkout.

Is the following implemented? If not create a spa ticket for future.

• If item A is added to the cart, and at the time there was stock, but then you load the cart later and the item becomes out of stock, we display a message stating that the item was removed from the cart due to out of stock.

Come up with a mechanism to release our libraries to npm from Travis CI using a specific set of branches or tags

When we moved Spartacus to open source, we concentrated on 1808.

The instructions are similar but not the same for 1811, so would be good to make a copy and label them 1808 and 1811 respectively.

Some things I know so far:

• We're still telling people to download the spaccelerator impex.
• Fixes were done in 1811 that solve the issues of checkout, so those parts should be removed.
• Would be good to retest the instructions on 1811 and remove anything else that might not be needed, that was special for 1808. Good to involve interns again.

• Test adding different quantities. (1,2,3) and assess that there is a correct number difference on the minicart.

• Test the different operations the user can do from the add to cart modal
  -- change qty
  -- close
  -- view cart
  -- procede to checkout

• Asses that the following are as expected:
  -- title.
  -- ID
  -- Price
  -- Short desc
  -- stock level
  -- pictures
  -- Tabs have the expected content:
  --- Product details
  --- Specs
  --- Shipping
  --- Reviews
  ---- Assess that we can submit a review without an error (and ideally asses that the review displays. May depend on the default backend settings, reviews need to be approved in backoffice before thay are displayed )

While the complete storefront can be added in one go by using the cx-storefront component, customer sometimes use the commerce storefront partially. Some customer would only use the checkout flow, and have other areas of the storefront being rendered in a separate system.

We need to validate and most probably rework the organisation of our storefront:

• validate whether partial components can be used separately
• expose modules in a clean way, so that library consumers know what should be pulled in
• optimise build (code splitting, tree-shaking) so that only required code will be shipped in the app bundles.

Also #1153

Tasks related to the general Account Profile page: name, password, email, consent.

A number of areas in the storefront is driven by configuration. The commerce backend API (baseUrl) is good example. Angular-cli provides a mechanism for different configurations per environment, but at the end of the day, the configured baseUrl is baked into the JS code. This means that the application cannot be deployed to various environments (dev, qa, prod); a new build is required for each and every environment. The same is true for the pipeline; the pipeline's backend must be aligned with the baked in configuration.

When we deploy the JS app on a server, ideally, the server should provide a configuration to the JS app when it's served. Dev-ops can than reconfigure the backend baseUrl, and with the next request, the JS app will interact with the newly given baseUrl.

There are different possible solutions, none of them are standard (not in angular(-cli) nor in JS world).

• Provide a local config file in the JS app that can be read before the app start to bootstrap
• Provide a http header in the index.html
• Provide a script tag in the index.html
• Provide a meta-tag in the index.html

There a number of things we try to achieve/ avoid:

• we do not want to do a separate network request (which is the case in 1 and 2)
• we want a server agnostic solution
• we want an easy to use solution (2 is complicated for non-webserver devs)
• we want a layered approach (means, we could do multiple solutions, with fallbacks)

Based on this, we envision:

The storefront looks for meta-tag with a specific name, indicating the commerce backend base URL

<meta name="occ-backend-base-url" content="https://localhost:9002" >

If the meta tag is not available (can be empty though), the config will fallback to configuration (what we have today). Customers can decide to configure the baseUrl or use a proxy to reroute the request.

This architecture should be reused for other configurations, such as other backends.

We've started a mock server implementation, using json-server and faker.js. The goal of this mock server is to be up and running for devs so that they can start right away without being dependent on a commerce backend. (no commerce backend required). Other advantages are around mocking unit tests, e2e testing, and implementing new features for those areas where there's not yet a backend ready.

Currently the mock data can be generated for a commerce backend. The sample data is outdated, and this is the main thing we like to fix in this epic:

• complete mock data
• generate sample up-to-date sample data
• consider using the mock server for e2e

In addition, we need to publish the mock/sample data in an npm package, so that it can be versioned and pulled for projects.

We might want to do this with the following approach:

1. update existing or create a new sample data set (that's in the backend)
2. generate the mock data from the sample data set

This approach gives a number of advantages:

• we can regenerate with each and every release
• our e2e tests will validate our storefront against the sample data we deliver
• customer can regenerate the sample data for their own projects, e2e tests, etc.
• existing commerce applications can benefit from the data sets
• we can run parts of the app with mock data and others with a real backend

In SPA-850, we added fired promotions to cart. For some reason, potential promotions aren't appearing. Creating this ticket and assigning to Bill to talk with promotions team and figure out where that data is.

Improve the current product search e2e test: https://stash.hybris.com/projects/C3PO/repos/spaccelerator/browse/projects/storefrontapp-e2e/src/suites/product-search.e2e-spec.ts

EDIT: github link: https://github.com/SAP/cloud-commerce-spartacus-storefront/blob/develop/projects/storefrontapp-e2e/src/suites/product-search.e2e-spec.ts

We should cover:

• Sorting
• Pagination
• Filtering with the facets
• Layout toggle

This ticket is for implementing the customer's Payment Management page.
We need to add cms in the backend but you can use page label for order history in the meantime.

Tasks

• ux design
• sandbox (SPA-400 and 421)
• implement
• unit tests
• e2e tests
• proper cms label

General behavior

Go to the page and there are already addresses

Display cards of existing addresses, like checkout
https://98qkkl.axshare.com/#g=1&p=addresses_added

Go to the page and there are NO addresses

Display empty form by default
https://98qkkl.axshare.com/#g=1&p=spa-179-addresses_empty

Deleting Addresses

Clicking Delete displays "are you sure" inside the box
https://98qkkl.axshare.com/#g=1&p=addresses_delete

Setting Default Address

Clicking "Set as default" sets the address as default, and it moves to first spot.
Confirmation message appears at top.
https://98qkkl.axshare.com/#g=1&p=addresses_setasdefault

Click Add or Edit

Add

Clicking Add shows the form with fields blanked with intro text "Add a new shipping address."
Like: https://98qkkl.axshare.com/#g=1&p=spa-179-addresses_empty
Remember the country/state thing in checkout, same thing.
For default country, use same country as the user's default address (if there is one).
Otherwise use same behavior as checkout.

Edit

Clicking Edit shows the form with fields filled in, with intro text "Edit an existing shipping address."
Like: https://98qkkl.axshare.com/#g=1&p=spa-179-addresses_empty
but with info.
Ignore the wire https://98qkkl.axshare.com/#g=1&p=addresses_addform, it's a bit weird.

State/Province/Regions

Don't forget that if there are no state/regions for a country, hide the state/region menu.
The backend will give an error if you supply an invalid state/region code, but is ok if there is none at all.

Set as Default when adding and editing

• If there are no addresses yet, don't display check box "Set as default address"
• If there exists one other address, display check box "Set as default address"
  If checked, make this address the default.

Forms and Verification

Copy what we have in checkout.

Address Verification

Trigger address verification when user clicks Save.

Canceling

Clicking cancel drops the changes and goes back to the list.

Out of Scope

• The UX has a menu at left, but we left that out so far

Tasks realted to implementing accessibility.

The contributions document mentions the CLA.
"Contributor License Agreement" section

What's not clear is that you don't need to 'sign' the CLA until you make your first PR.
The PR status page will list all the things that have to happen to accept the PR:

• CI is passing
• A maintainer reviewed the PR
• CLA is signed

If CLA is not signed, there is a link to do so. Only then does the spartacus repo show up in that menu in cla-assistant.io.

We need to introduce type safety on a lot of layers, but at least on the facade layer (#6). We've already generated types from out OCC backend (using swagger.json and a standard generator), and ideally we use those generated types.

Type safety provides static code validation and helps customers to develop faster.

The route configuration requires several enhancements:

• configurable routes – the routes are hardcoded, which means it cannot be customised
• localised routes – different languages or brands requires localised routes for the same route
• nested routes – only first-level routes are used with a single route outlet, we should consider nested outlets

We like to fully adapt CSS custom properties in order to:

• runtime configurability (no need to rebuild the system)
• easy customisation
• avoid strict view encapsulation for theming and customisation (shadow DOM, CSS vars peers through it)

We've experimented with this approach in https://github.com/tobi-or-not-tobi/lipstick-css and the recent decision to drop Internet Explorer 11 has strengthen our decision here (no need for fallbacks).

This is an important input in our rework on the UI framework, see #10.

Bill created CONTRIBUTING.md for early October; Wei did a preliminary review (see SPA-1367) and I made updates.

We need all developers to study and provide feedback to ensure the process reflect our working model and improves efficiency.

• Wei
• Gil
• Nik
• Patrick
• Louis
• Kate

We can provide an angular schematic to simplify the creation of custom components, routes, page templates, etc. This will help to:

• customise very fast
• customise according to our best practice
• avoid reading documentation

Angular schematics are the technique that can be used for this.

Epic for topics related to address management page

For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.

The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.

For E2E purposes, some suggestions related to how we get data from the backend:

• Check that the menu is there and populated (even if there is only 1 language right now it's still there I think)
• Changing the language refreshes the whole site
  ** ... but stay on same page/view/screen.
  *** In fact if you are in the middle of registering and change the language, your entire form should remain the same.
  ** Check that the text has changed to target language.

Product details page is a good one to make assertions from, as well as registration page for forms.

• Another test: do a browser refresh after switching the currency/language, to make sure the change sticks beyond the explicit change request from the user. (and doesn't fall immediately back to the default)

The backend sampledata provides English, German, Chinese and Japanese.

Note that language and currency e2e tests are similar in scope - see SPA-945.

While the architecture is completely driven to allow for upgradability, there will be breaking changes from one version to another that wil make upgrades less seamless as we'd like. Also, dependency management can cause a lot of time for app developers for each and every (larger) release that we bring. Therefor we like to use angular schematics to allow for a seamless upgrade of dependencies and other breaking changes we might do.

 
Task: Add any negative tests to Added to Cart Modal. Either as functional, integration, unit test.

For example:

• Attempt to remove twice from modal.
• Attempt to click on "Add to Cart" while modal is displayed. (One click only)
• etc

Use your imagination :)

Please note pull request [https://stash.hybris.com/projects/C3PO/repos/spaccelerator/pull-requests/122] doesn't include any sort of negative tests.
See definition of done

• Change y- prefixes to cx- in component selectors in .ts and in .html.
• Update tslint rule to remove y-.
• Run automated tests after.

Separate ticket for styling: #43.

Previous internal ticket: SPA-1218
Main selector was changed in: SPA-1219

For runtime performance reasons we need to move into an architecture where different parts of the application are lazy loaded. Angular provides lazy loading out of the box, however the lazy loaded elements are driven by the router. The router is typically related to "pages". This works well in case the page content is determined during design time, so that the code can be split up at build time. But with CMS driven pages, where the page content is composed at runtime, this technique doesn't fly. A smarter approach is required to allow for a good mix of CMS driven pages and lazy-loaded techniques.
We basically need to lazy load components. The granularity can be decided, but CMS components should be lazy loaded (although a few of them could be bundled together) as they can be added to any CMS page at any time.

Some things to keep in mind:

• lazy loading and SSR might conflict as the initial served page already has some components. These components shouldn't be reloaded
• Angular elements could be leveraged, but the current footprint for bootstrapping is probably to big (until we get ngivy)
• web components could be the answer, but we must carefully evaluate browser support and the size of polyfills to enable it

The readme's are already pointing to https://stackoverflow.com/questions/tagged/spartacus-storefront but we don't yet have the tag.

Page templates control the overal layout of a page and can be selected by business users in the CMS. Our storefront UI must have a clean list of page template components, which only represent a CMS page templates from the backend. The current implementation has a number of issues:

• Multiple page templates have been introduced lately for no good reason, we need to clean this up
• Page templates and page components are redundant. We can drop the page components and route directly to the page template component. This is related to the work in #3.
• Page templates should only represent the "page", any sub sections (i.e. myaccount/addresses) should reuse the page template (and could introduce nested router outlets, see again #3.

Looks like Roman did changes to styling too.

This ticket is to make sure Roman got them all, otherwise move back to PO column.

Github issue to change prefixes in code: #42
Previous internal ticket: SPA-1220

The storefronts is driven by different content streams. Most of the content is driven by either the CMS or by the product content. There's however a portion of content that is provided by so-called site labels.

Site labels are in the current storefront solution (spring mvc based) based on java resource bundles, which gives some issues:

• they cannot be controlled by business users and require a full development cycle
• they aren't exposed through a webservice
• they do not have any structure (it's a flat list, although they're separated over multiple files)

There's a lot of room for improvement. We like to setup a solution that provides:

• runtime language switching
• lazy load languages
• avoid hardcoded text

Angular doesn't provide these features yet, but have hired the author of translate to build this is as a standard feature in Angular. This takes longer then expected and it's recommended to start embracing ng-translate so that we can relatively smoothly transition to the standard solution (probably beyond ng7 and in parallel with ngyvi).

(Using backend dev-com2 and just-registered user without any addresses added before):

When a user goes to checkout (address form) and refreshes, then after reload there are many errors in console of the same type:
{code:java}
ERROR TypeError: Cannot read property 'childs' of undefined (NavigationComponent.html:2){code}

Search listings: Facet UI unit tests

For each time we release on github, we need to include a change log that lists the changes that belong to the release. Here's an example:

https://github.com/angular/angular-cli/releases

And here's the angular script that generates it:

https://github.com/angular/angular-cli/blob/master/scripts/changelog.ts

The code base has grown lately and a bit of clean structure is missing. We like to improve this with 2 changes:

1. split up storefront lib in 2 libraries
2. reorganize UI components

Split up libraries
Currently the storefront is implemented in two main libraries: storefront and styles. In order to scale better and separate out the framework bits and UI components, we need to separate those out over 2 libraries. Other storefront dev teams (i.e. telco, fsa) can then start building their own UI component lib with a dependency on the core lib only.

The tasks foreseen for this epic are:

• move out UI components to new library
• rename storefront library (core seems to be the right name)

Reorganize UI components
TBD

New server is: https://storefront.c39j2-walkersde1-d4-public.model-t.cc.commerce.ondemand.com

While our commerce backend is really strong with multi-site capabilities, this has not yet land fully in the Spartacus storefront. We already support multi-site with a configuration property, but the true multi-site features require:

• a lookup on the storefront domain in the backend. This is done in commerce cloud by default for accelerators, but must be added here. It requires a new endpoint that takes the current location (url).
• an endpoint that provides all (available) stores / sites, so that we can build a site landing page (i.e. "select your country site")
• allows for multiple catalogs for sites that are driven in a multi-country fashion

This ticket is to regression test all facades.
Documentation is #416.

Original master description:

While we're using ngrx store inside, we like customers to not necessarily be bother with the complexity of ngrx. Moreover, we might want to move (partially) to other state management solutions in the future. We've already started to build a facade layer on top of ngrx store, and must finalise this for all ngrx services.

• add facades as services in a facade folder
• all methods should be public or protected (assess as we go)
• any components/services outside store should use facades instead of use store directly
• update all tests (outside store) to use facades, remove StoreModule from tests if possible

Spike was done as part of #140. Tobias and Wei working on it and probably done eod Nov 1.
It can be used as an example for the facade (but not the move).

General epic for adding missing E2E and unit tests. For new features, these are part of DoD.

To reproduce:

• Go to mobile view in chrome or firefox
• Try searching for any term (not camera)
• Results won't show up

In angular we don't use the class element IDs and therefor we can't do:

<label for="FORM_CONTROL_ID">label text</label>
<input id="FORM_CONTROL_ID">

Instead, we should ideally do:

<label>
  label text
  <input>
</label>

This is both a fix as well as a simplification. 

This should be fixed in the various forms we have (login, address forms, checkout, etc.)

For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.

The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.
h2. 1. Error situation + check what happens when user tries to register with existing username

• Register a user with an email that is already registered
• Should get an error message (global messaging for registration)
• Angular page stays on same page; user can keep trying to register
• Most information remains on page
• And the valid user should not be blocked from logging in
  ** Unless there is some kind of protection if you try 5 times or more
• Because if this breaks: something changed in the backend
• Future: Captcha?

h2. T&C link

• Clicking T&C gives you the page and OK response

h2. Cart merging tests that aren’t in big e2e test

• Anonymous user has items in cart, logs in, new cart has all items
• Logged in user adds items to cart, logs out, adds items to cart, logs in, carts merged

The following would be Angular unit tests as they don't touch the backend.

• Not allowing submit if salutation not chosen, fields don't meet requirements, etc.
• Email or password validation
• Not allowing submit if T&C not checked

For other E2E tests, we decided to focus on where backend adds value or can influence or cause breakage.

The assumption is that these kinds of tests are in addition to what Stan already is working on, so check with him. E.g. you can register successfully, and the user is logged in.

For E2E purposes, some suggestions:

• Check that the menu is there and populated (even if there is only 1 currency right now it's still there I think)

• Changing the currency refreshes pricing only

** ...but stay on same page/view/screen.
** In fact if you are in the middle of checking out, adding an address in a form, and change the currency, your entire form should remain the same.

Product details page is a good one to make assertions from. Check that prices updated to expect new amounts. But also, a checkout form like shipping address to ensure the user's data isn't erased.

Also: do a browser refresh after switching the currency/language, to make sure the change sticks beyond the explicit change request from the user. (and doesn;t fall immediately back to the default).

The backend sample data has US dollars and Japanese Yen, 

Note that language and currency e2e tests are similar in scope - see SPA-944.

Currently our UI framework of choice has polluted all UI components. This is bad for customers who do not or cannot use bootstrap. We want our UI layer to be independent on a specific UI framework. Moreover, we should avoid a mandatory peer dependencies like bootstrap and ng-bootstrap.

This requires a number of poc's (such as https://github.com/tobi-or-not-tobi/agnos) and rework.
The goal of this work is:

• a very clean and standard UI layer (html5, avoid UI framework specific markup)
• a mapping, extension, pre-processing technique that can be applied to our standard UI

With Agnos I've learned that SASS is a great choice for UI framework agnostic approach:

• all large frameworks use sass
• sass has an @extend mechanism
• sass has a placeholder selector (which no one seems to use though :( )

But, we're open to other approaches.

An alternative approach is obviously a design system. ng-bootstrap is an example of this, but there are big hesitations with this:

• it's a lot of work (been there, and have seen how much time good design systems take)
• customising is a lot of work still, although its more cleaner

This ticket is for implementing the customer's Account Profile page.
We need to add cms in the backend (SPA-1416) but you can use page label for order history in the meantime.

Wires are: https://98qkkl.axshare.com/#g=1&p=spa-143-_profile
but waiting to hear if they are final.

Tasks (can be split into separate issues, use epic profilepageimpl):

• ux design
• sandbox
• implement
• unit tests
• e2e tests
• proper cms label

The new Account page combines items that were separate pages in Accelerator: changing name, email, password, or consent preferences, as well as closing your account.