Switching between stores
If you can administer or have access to more than one store, you can change your context
store anytime after you log in to Sterling Store Engagement.
About this task
As a store associate or store manager with permission to access multiple stores or as an
enterprise user with permission to access multiple nodes, you can:
- Log in to a default store or log in to the same store that you last logged in.
- Switch to a different store anytime after you log in.
As an enterprise user, the store that you log in when logging in to Sterling Store Engagement for the first time is determined as the default store.
Based on the resource permissions, you can change your context store. To enable resource permissions, open the Applications Manager. Go to , and enable StoreSwitcher.
Here, ISF_Product_Name refers to Sterling Store Engagement next generation. For more information about setting up resource permissions, see Administering user group permissions.
Note: You can also switch to a different store by passing the StoreId query
parameter in the URL. For example,
http://<IP_ADDRESS>:<PORT>/isf/store-frontend/index.html?StoreId=<yourStoreId>.The following points explain how the various use cases for this feature are implemented:
Store users can log in to a default-assigned store
- The logged-in user is validated for a ship node with the
currentUseron session post authentication. If a default node exists, the user is identified as a store user. - The current logged in store user information is saved by calling the
manageUserUiStateAPI. - The user and store context are set and the home page is loaded.
Store users who have access to multiple stores can log in to the store last logged in
- The logged-in user is validated for a ship node post authentication. If a default node exists, the user is identified as a store user.
- The
getUserUiStateListAPI is called to validate whether the last logged-in store is the same as the default store. If it is not, the last logged in store is validated against theAccessibleOrganizationsof the user. - If the user still has access, the application continues to log in the user to the last logged-in store, else the user is logged in to the default store.
Enterprise users can log in to a default store
- The logged-in user is validated for a ship node with the
currentUseron session post authentication. If there is no default node, the user is identified as an Enterprise user. - The
getUserHeirarchyAPI is called to check if there are accessible ship nodes. If there are accessible ship nodes, one of the nodes is set as the default. - If there are no accessible organizations, the
getTeamDetailsAPI is called to read the team configuration (ShipNodeAccessMode). - If
ShipNodeAccessModeis01, thegetShipNodeListAPI is called to get all the nodes for the logged-in Enterprise and one of the nodes is set as the default. - The user and store context are set and the home page is loaded.
Enterprise users can log in to the last-logged in store
- The logged-in user is validated for a ship node with the
currentUseron session post authentication. If there is no default node, the user is identified as an Enterprise user. - The
getUserUiStateListAPI is called to check if there is a record of the last logged-in store for the user. - If yes, the
getUserHeirarchyAPI is called to see if the user has anyAccessibleOrganizationsand is validated against it - If
getUserHeirarchyAPI does not return anyAccessibleOrganizations, thegetTeamDetailsAPI is called to readShipNodeAccessMode. - If
ShipNodeAccessModeis01, thegetShipNodeListAPI is called to get all the nodes for the logged-in Enterprise and the user is validated against it. - If there is no previously logged-in store for the user,
getUserHeirarchy/getShipNodeListAPI is called and a node is set as default.