diff options
Diffstat (limited to 'design-documents/015-merchant-backoffice-routing.rst')
-rw-r--r-- | design-documents/015-merchant-backoffice-routing.rst | 31 |
1 files changed, 14 insertions, 17 deletions
diff --git a/design-documents/015-merchant-backoffice-routing.rst b/design-documents/015-merchant-backoffice-routing.rst index 07aee233..71a0e554 100644 --- a/design-documents/015-merchant-backoffice-routing.rst +++ b/design-documents/015-merchant-backoffice-routing.rst @@ -1,21 +1,21 @@ -Design Doc 015: Merchant backoffice Routing -########################################### +DD 15: Merchant backoffice Routing +################################## 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. @@ -55,10 +55,10 @@ There are 2 type of routing: instance and internal doest not need to care about matching all applications URL Knowing that the $BACKEND_URL points to a correct merchant backend the SPA will -check for ``$BACKEND_URL/private/instances``: +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/private/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. - - - |