Define product hierarchy / new URL structure - COMING Spring 2022

[severinbeauvais]

1. Document what we want the product hierarchy to look like (including various home/landing pages) 2. Document what the URL structure/routing should look like 3. Implement this -- create / see child tickets for various teams/products!

Story Description:

As a user:

• I want a single point of entry into the BC Registries applications so I don't have to remember separate URLs and so I can discover what else I can do (E.g., https://bcregistry.gov.bc.ca)
• I want to be able to easily navigate between BC Registries applications so I stay within this domain to work on multiple businesses (or PPR or whatever) and can easily understand where I am. (E.g., up/down or back/fwd buttons, or breadcrumbs, or navbar, or whatever)
• I want to be able to bookmark any of the BC Reg web apps so I can go straight to it. (#2333)
• I want URL paths that make sense so I have an idea where I am. (I.e., not everything under '/cooperatives')

As a developer, I want the various applications to fit under URL paths in a logical and easy-to-configure way (re: routing between web apps).

Dependencies

• We assume the root URL will be https://bcregistry.gov.bc.ca
• Existing web apps may need configuration changes for new base app path(s).
• The old URL to Cooperatives Online should continue to work (using HTTP redirect?).
• All teams implementing a BC Registry web app need to be involved.

Acceptance Criteria TBD

Validation Rules TBD

Ready for Sprint (DoR)

• [ ] Do we have a prioritized Sprint backlog?
• [ ] Defects, user stories and other work the team has committed to are contained in the sprint backlog?
• [ ] Any hidden work?
• [ ] All team members availability & capacity is known for the sprint?
• [ ] All users stories meet the definition of Ready?

Ready to Build, Story level (DoR):

• [ ] Have Stakeholders approved this story?
• [ ] Does User story have full flow of business rules, happy and alternate paths etc. ?
• [ ] Are the dependencies known/understood?
• [ ] Dev team accepts user experience artifacts?
• [ ] Are the validation rules defined? (UI, Data, Role-Action)
• [ ] Is a formal UAT required for this user story?
• [ ] Are the acceptance criteria well defined in this ticket (Story level) that QA can confirm or deny ?
• [ ] Does user story need to reference BA checklist? ( are functional/Non functional descriptions captured ?)
• [ ] Is the person who accepts this user story as complete identified? (PO)
• [ ] Can this User story be sized by the Dev. team ?
• [ ] Can this User story be demoed to show value?
• [ ] Is this user story small enough to be completed in a sprint?

Acceptance / DoD:

• [ ] PR to remove feature flags created
• [ ] Check Requirements against completed stories
• [ ] Completed stories verified in Dev/Test/Prod
• [ ] Confirm Test cases built and succeeding
• [ ] Confirm successful End-End runs
• [ ] No regression
• [ ] All Linters passed
• [ ] Test coverage and Test ID acceptable by Product owner
• [ ] Ticket merged to master or story branch
• [ ] Add / maintain selectors for QA purposes
• [ ] Add PR numbers - If available
• [ ] All tests passed (Jest, Pytest, Postman)
• [ ] Developer to list Config changes/ Update documents and designs
• [ ] Design / Solution accepted by Product Owner
• [ ] Acceptance criteria has been defined (happy path, known sad paths)
• [ ] Test coverage acceptable
• [ ] Peer Reviewed
• [ ] Accessibility reviewed and acceptable checklist
• [ ] UX Approved
• [ ] PR Accepted
• [ ] Production burn in completed

[severinbeauvais]

Proposed Hierarchy

This proposed hierarchy is designed to mirror the URL path hierarchy and GitHub project hierarchy.

URL path https://bcregistry.gov.bc.ca	GitHub project path https://github.com/bcgov	Comment
/		future BC Registry home page
/api		This needs to be discussed after a month
/api/legal	/lear/legal-api
/api/account	/sbc-auth/auth-api
/api/pay	/sbc-pay/pay-api
/api/namex	/namex	is this correct?
/api/developer		For external developer info
/api/assets		The PPR and MHR can be further slashed from this path
/business		This is for Business Registry homepage
/business/name	/namerequest	This is for Name Request
/business/create	/bcrs-business-create-ui	This is for incorporating a business
/business/filings	/business-filings-ui	This is for business filings
/business/search	/sbc-search	This is for search functionality
/staff		Future staff tools(account maintenance, admin etc). Business or Assets can "/" from staff
/account	/sbc-auth/auth-web	This is for user accounts
/pay	/sbc-pay/pay-ui	For now, we are leaving it here, team can decide later
/assets		This is the homepage for assets

[severinbeauvais]

@thorwolpert What should the Dev (and Test) environments be called (and do we need more URLs for that)?

• https://dev-bcregistry.gov.bc.ca ?
• https://bcregistry-dev.gov.bc.ca ?
• other?

Also, does the table above look OK?

[severinbeauvais]

@jeznorth @thorwolpert @pwei1018

We have had a few ad hoc conversations to discuss the approach here and I think we're generally in agreement. Can we finish discussing this and then document what we need to do to implement this?

• [ ] step 1
• [ ] step 2
• [ ] step 3

Update: see #2975

[pwei1018]

@saravankumarpa Can you work on this with Severin?

[saravankumarpa]

@severinbeauvais My two cents on this. I was under the impression that we are migrating only our front end apps to new urls. But looks like we are planning for API's as well. API's can be more of api.bcregistry.ca/foo etc... It need not to match the webapps pattern. for example Githubs API's are https://api.github.com/user etc. We need more discussion on that. Again with respect to API , some more things has to be considered . Since API manager will get involved , it will be the front facing for public API and then the APIS will be exposed via API Manager. The API's doesn't lie on the same namespaces in openshift , that might also has to be considered while naming them since openshift has restriction on the routes ;or else the proxy have to support some kind of mapping.

[severinbeauvais]

@thorwolpert Can you respond to Saravan's comment please?

[thorwolpert]

the APIs will get consolidated as part of the API Gateway work. I don't think that it is worth working towards an interim spot, as opposed to just moving to the Gateway this Spring/Summer.

[trishreimer]

If the URL actually changes from what it is today, we will need to advise staff and update existing web pages, job aids, materials, etc. I'm assuming a redirect will be in place to direct clients to the new URL. Based on a conversation with KM, we may want to use this as an opportunity to create a new brand for Registries, so at a minimum, I would suggest discussing the naming convention with KM.

[jyoti3286]

The proposed hierarchy table has been updated based upon the discussion between Thor, Severin, Loren, Kaine, Jyoti, Sumesh, Bryan. "/api" path can be discussed in the future(post 1 month)

[lmullane]

@severinbeauvais @pwei1018 Isn't this done?

[severinbeauvais]

@lmullane We have an idea what the URL structure should look like but I'm unsure whether everybody is OK with it, whether it's complete, and whether it's properly documented anywhere.

If you look at the top of this ticket, I'd say # 1 and # 2 are sort of done, and # 3 needs to be done.

[Kaineatthelab]

We also never implemented the new URLs for the public, so still, need to do this transition. Since we haven't done this we could probably have another meeting around it and plan to put this in in the next 2-3 months?

[lmullane]

Sounds good, @Kaineatthelab @severinbeauvais

Looping in @sumesh-aot and @saravanpa-aot

[sienna-oldaccountdontuse]

@jyoti3286 please bring to next PO sync

[jyoti3286]

@thorwolpert @sumesh-aot Whats the next steps on this item?

[sienna-oldaccountdontuse]

Will look at this ticket again after the registry app architecture has been decided

[sienna-oldaccountdontuse]

@Kaineatthelab do we want to keep using this ticket? Do we need updates to it?