[L] View list of Sites associated with Protected Areas

[Dianadec]

Description:

As a BC Parks Admin user, I would like to view sites associated with a Protected Area so that I can find the information I need.

This page shows how Sites will be displayed on the main park page for MVP. When we have more data (campgrounds etc), this page will change but the sites module as shown here will likely be reused.

Acceptance Criteria:

Given that I am a BC Parks Admin User When I view a Protected Area record Then I can see a list of the Protected Area's associated Sites as a list with links

Given that I am a BC Parks Admin User When I click the link of a Site Then I am taken to the View Site Record screen

Development Checklist:

• [x] Site header uses the same formatting as "Legal name" and "Historical name"
• [x] Site Links:
• • [x] links display the site ID in bold. Display the legal site name in normal. ex: 308-1 Burton Site
• • [x] Leading zeros on site IDs are not needed. (We will be removing the leading zeros from protected area IDs as well.)
• • [x] links go to View site record screen

Wireframe(s): Note: everything inside the green dotted line is already developed and shown for reference. https://www.figma.com/file/qdjegD6YHWZPlyFT8dGXvk/Data-Register?type=design&node-id=3837%3A12423&mode=design&t=TgFV6bzm5hIqy5eN-1

Workflows: https://www.figma.com/file/qdjegD6YHWZPlyFT8dGXvk/Data-Register?type=design&node-id=3898%3A2585&mode=design&t=Wja03WX4eAWFIV6w-1

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

• [x] User story is included
• [x] User role and type are identified
• [x] Acceptance criteria are included
• [x] Wireframes are included
• [x] Design / Solution is accepted by Product Owner
• [x] Dependencies are identified (technical, business, regulatory/policy)
• [ ] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

• [x] Acceptance criteria are tested 
• [x] UI meets accessibility requirements
• [ ] Passes code peer-review
• [ ] Reviewed and approved by Product Owner
• [ ] Code is peer reviewed and has passed CI/CD tests
• [ ] Unit tests are written
• [ ] Code is shippable to the production environment
• [ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment
• [x] Functional features have been tested and passed by QA
• [x] Functionality meets the acceptance criteria defined in the ticket
• [ ] Product Owner has reviewed the functionality and approved 
• [ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)
• [ ] Work is traceable in GitHub
• [x] BC Web Accessibility and Inclusion Standards are met
• • [x] 1. Keyboard navigation
• • [x] 2. Proper Semantic markup (form fields and controls labels)
• • [x] 3. Colour Ratio is 4.5 to 1

Notes:

• This piece was broken out from the original ticket: https://github.com/bcgov/parks-data-register/issues/124

Dependencies

• Blocked by
• Blocking

[cameronpettit]

@Dianadec Minor point of clarification on this ticket - I can set up the routing so clicking on a site link will take you to the site's details page, but there will be nothing on that page indicating which site you've navigated to as that functionality to GET specific site details is implemented in #406. Wondering if its still ok to consider this ticket done if that is the case?

[Dianadec]

@cameronpettit I think that's okay. CC'ing @JLWade

[cameronpettit]

Wanted to drop this in here for potential future reference - this is an example of how we leverage Angular's routing system to render components based on the url route. In short, every stage of the route may have 0, 1, or both of the following:

• a component that is rendered for that route and all child routes
• a router outlet that houses child components rendered by child routes

Dissecting this image, we see:

1. The root data-bcparks/admin.ca renders the sidebar, header and footer, and provides an outlet for:
2. /protected-areas has no rendered component but is the root for everything related to Protected Areas, and provides an outlet for:
3. /308 is the specific protected area id and is the root for everything related to PA 308. It renders the specific protected area name header and provides an outlet for:
4. /details, which contains components specifically to do with 308's details, like historical names and site list. There is no router outlet because it is expected to be a terminal route.

From my understanding, sites are hierarchically nested within protected areas, so a route to a specific site might look something like this

• data-bcparks.ca/admin/protected-areas/308/:siteId, or
• data-bcparks.ca/admin/protected-areas/308/sites/:siteId

Based on the information above, a site page would also render the protected area name header listed in 3) as 308 is part of the route, but the designs don't show this.

We can structure our route-rendered components to match designs but it is worth pointing out that we forego certain efficiencies by doing so. It's not something we've really run into before but it will be worth considering moving forward as it will be very applicable to displaying nested data in the Register.

No action needed yet, I just wanted a place to document this point.

[manuji]

Tested on TEST: Passed

• Verified that the list of sites associated with the park are displayed on the view page.
• Verified that the each site item includes a link.
• Verified that the link takes the user to a new page -> this page is still in progress and not in scope for this ticket.
• Passing this to PO review.

[JLWade]

I can see the sites and click on them! I like the coming soon note :) Moving to done