summaryrefslogtreecommitdiff
path: root/design-documents/015-merchant-backoffice-routing.rst
diff options
context:
space:
mode:
Diffstat (limited to 'design-documents/015-merchant-backoffice-routing.rst')
-rw-r--r--design-documents/015-merchant-backoffice-routing.rst25
1 files changed, 11 insertions, 14 deletions
diff --git a/design-documents/015-merchant-backoffice-routing.rst b/design-documents/015-merchant-backoffice-routing.rst
index f6372dcc..7362642e 100644
--- a/design-documents/015-merchant-backoffice-routing.rst
+++ b/design-documents/015-merchant-backoffice-routing.rst
@@ -6,16 +6,16 @@ Motivation
==========
A well defined routing will allow users to share backoffice links pointing
-directly into instance pages (settings, orders, products, etc...)
+directly into instance pages (settings, orders, products, etc...)
-The backoffice should load from the instance URL and then allow a internal
+The backoffice should load from the instance URL and then allow an internal
routing of the views with the possibility to accessing them directly when
sharing a link.
This 3 definitions are going to be use in this document:
-* BACKOFFICE_URL as the url where the app is loaded.
-
+* BACKOFFICE_URL as the url where the app is loaded.
+
* BACKEND_URL as the url where the merchant backend is.
* INSTANCE the name of the instance being manage
@@ -27,13 +27,13 @@ Application Ready definition
The application is considered ready after
* the user tried to login.
-
+
* the application checked that the backend url points to a merchant backend
* the merchant backend response successfully
The backoffice test for ``$BACKEND_URL/config`` to define if the $BACKEND_URL is ok.
-The application can potentially test if the protocol or version matched.
+The application can potentially test if the protocol or version matched.
While the application is not ready, just the top navigation bar will be shown
with a message in the left and the lang selection option.
@@ -58,7 +58,7 @@ Knowing that the $BACKEND_URL points to a correct merchant backend the SPA will
check for ``$BACKEND_URL/management/instances``:
* if Unauthorized ask for credentials
-
+
* if error check with the user
* if not found, then url should end with ``/instances/$INSTANCE``. otherwise is
@@ -69,11 +69,11 @@ check for ``$BACKEND_URL/management/instances``:
When a user access the SPA there are 3 scenarios possible:
* **standard**: admin is false so BACKEND_URL points to a non-default instance.
- standard features and links are shown
+ standard features and links are shown
* **admin**: admin is true so BACKEND_URL point to default instance. same as
before and user can create and list instances with some additional links in
- the sidebar.
+ the sidebar.
* **mimic**: admin is true and the request parameter "instance" is set $INSTANCE
instance. BACKEND_URL point to default instance but the user is managing
@@ -99,7 +99,7 @@ parameter (like order id or product id) it should be accessible from the Sidebar
If the user has admin access, this entry points are available:
- /instances: Show the list of instances currently created
- - /instance/new: Show a instance creation form
+ - /instance/new: Show an instance creation form
Where admin or not, there is also this entry points:
@@ -145,7 +145,7 @@ credentials or the backend url
Not found
---------
-For any case that the backend respond 404 the application will render a
+For any case that the backend respond 404 the application will render a
custom not found page
Default instance is missing
@@ -155,6 +155,3 @@ If the **user is admin** AND is loading the setting page (/update), product list
(/products), order list (/orders) or transfer list (/transfers) AND **gets a
404** it will tell the user that it need to create a default instance before
proceeding.
-
-
-