notes/customer_manager.org

notes/customer_manager.org

@@ -13,16 +13,16 @@
   - [[#questions][Questions]]
   - [[#remarks][Remarks]]
   - [[#quick-wins-along-the-way][Quick wins along the way]]
-    - [[#cross-region-links][Cross region links]]
-    - [[#local-account-switch-tenancy-switching][Local Account Switch (Tenancy Switching)]]
-    - [[#backend-to-backend-oauth2-tokens-exchange][backend-to-backend OAuth2 tokens exchange]]
-    - [[#org-level-credentials][org-level credentials]]
+    - [[#q2-cross-region-links][[Q2] Cross region links]]
+    - [[#q2-local-account-switch-tenancy-switching][[Q2?] Local Account Switch (Tenancy Switching)]]
+    - [[#done-backend-to-backend-oauth2-tokens-exchange][[DONE] backend-to-backend OAuth2 tokens exchange]]
+    - [[#q3-org-level-credentials][[Q3?] org-level credentials]]
   - [[#intermediate-steps-optional][Intermediate steps (optional)]]
-    - [[#cross-region-account-switching][Cross region Account switching]]
-    - [[#organization-managements-once-we-have-a-deployed-a-global-node-that][Organization managements Once we have a deployed a global node that]]
-    - [[#customer-selection-][Customer Selection (?)]]
-    - [[#customer-invitations][Customer Invitations]]
-    - [[#tenant-management][Tenant management]]
+    - [[#-cross-region-account-switching][[?] Cross region Account switching]]
+    - [[#-organization-managements-once-we-have-a-deployed-a-global-node-that][[?] Organization managements Once we have a deployed a global node that]]
+    - [[#-customer-selection-][[?] Customer Selection (?)]]
+    - [[#-customer-invitations][[?] Customer Invitations]]
+    - [[#-tenant-management][[?] Tenant management]]
 
 * Customer Manager
 
@@ -54,14 +54,14 @@ And thus, even if they are no more able to login inside SecureX, their
 clients will still work until their account is disable inside SecureX.
 
 ** Quick wins along the way
-*** Cross region links
+*** [Q2] Cross region links
 
 One easy problem to solve (probably for Q2) is to provide a region
 switching mechanism backed by an API.
 That way the UI will be able to provide a mechanism to help the user switch
 from one region to another.
 
-*** Local Account Switch (Tenancy Switching)
+*** [Q2?] Local Account Switch (Tenancy Switching)
 
 The API will provide two new routes:
 
@@ -82,7 +82,7 @@ The tenant/session is still  local to the domain name/application (SecureX/CTR/O
 The call to switch account should revoke the JWT to prevent a bug in the UI
 that will continue to use an older access token from the wrong org/tenant.
 
-*** backend-to-backend OAuth2 tokens exchange
+*** [DONE] backend-to-backend OAuth2 tokens exchange
 
 > *code already delivered, not deployed*
 
@@ -109,7 +109,7 @@ part of the document:
 certificate. Source application tenant is provided as part of the token request.
 #+end_quote
 
-*** org-level credentials
+*** [Q3?] org-level credentials
 
 We simulate the existence of an org-level user.
 We do not create a new entry in the DB, instead, we simply add a logic in
@@ -141,7 +141,7 @@ SCHEDULED: <2021-10-18 Mon>
 - [ ] scope to access the admin entities as a user
 
 ** Intermediate steps (optional)
-*** Cross region Account switching
+*** [?] Cross region Account switching
 
 The goal of this step is to deploy a new single global application API + UI
 that will help the user select their account across regions.
@@ -174,7 +174,7 @@ notion of /Customer Manager Session/ at the User-Identity level.
   I would guess deploy this on NAM, and the node will call the 3 IROH nodes.
   This will be the occasion to test the latency between nodes and see if this
   is not problem.
-*** Organization managements Once we have a deployed a global node that
+*** [?] Organization managements Once we have a deployed a global node that
 
 could makes call to all IROH nodes.
 
@@ -183,7 +183,7 @@ We could start to think about providing more and more API accesses.
 Typically one step could be a way to control the orgs from this centralized
 node.
 Typically, see all your orgs across all regions and disable/rename the orgs.
-*** Customer Selection (?)
+*** [?] Customer Selection (?)
 
 If we have a global node deployed where users could login
 
@@ -198,13 +198,13 @@ APIs managing these.
 - [ ] New stores to create: =customers= and =user-identities=.
   This change might force a DB Migration of the =users= DB in all IROH nodes.
 
-*** Customer Invitations
+*** [?] Customer Invitations
 
 We could probably reuse the SecureX invitation API to invite people into a
 =Customer= in the Customer Manager. This invitation will probably be a lot
 simpler as it will not involve SecureX org selection and a single region.
 
-*** Tenant management
+*** [?] Tenant management
 
 - At this step we should be able to login user at their User Identity level (SXSO login).
 - The User Identity should be linked to a single Customer(?).