BDMS-876: Projects view UI#296
Conversation
Includes project well counts, URL-based project filtering on the wells grid, indigo primary tokens, and filter pill styling.
Brings in the shared Card primitives used by the design system migration.
Moves useState, useEffect, and useOne above early returns so ESLint rules-of-hooks passes.
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
1 similar comment
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Tracks nav clicks, page templates, project row clicks, filter apply/clear, and project links on the wells grid.
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
|
Projects are more general than groupings of wells so I don't think the project view should be bound to wells so tightly |
|
Met with Cris and showed him the Project View table and where the editing capability would exist. He appreciated the view and mentioned a few additional fields he'd like to see, but I want to talk with a few more folks before making these formal requests. I did ask him about the nesting under Wells and he admitted that eventually we would probably want 'Projects' as a top-level, but for now having it under 'Wells' makes sense. In the interest of getting the editing capability underway, I suggest we move on. |
…ns to Groups list. The grid previously showed only name, parent group ID, a boundary checkmark, and created date. Added the remaining fields that the API already returns: description, group_type, release_status (rendered as a chip), well_count, and renamed the project_area column to "Has Boundary" to make the checkmark intent clearer. Also added group_type and well_count to the yup schema so they are not stripped on validation.
…lumns to Projects list.
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
1 similar comment
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
…se it in group and projects lists.
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
2 similar comments
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
…dary columns by default. Projects was nested under Wells in the sidebar. Lifted it to a standalone top-level item so it is directly reachable without expanding Wells first. Also hides the well_count, parent_group_id, and project_area columns by default in the Projects grid — they are still accessible via the Columns toggle.
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
3 similar comments
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
Preview DeploymentPreview URL: https://preview-bdms-876-projects-view-auejgdbofq-uc.a.run.app Note: This preview uses the staging API endpoints. |
|
I thought we were removing 'description', otherwise I think this looks good. |
|
One option instead of removing description is to use this as an opportunity to test out editing workflow. If we leave description field in we can then signal to the user that editing functionality is on its way |
Summary
?projectId=URL filter with indigo filter pill and clear behaviorTest plan
/ocotillo/well/projectsand confirm well counts displayDepends on
well_countandgroupsfilter (pointVITE_OCOTILLO_API_URLat API branch or staging after API merge)