fix(CP09): promote view columns onto the actual default view, not just the lookup view - #31
Draft
TomProkop wants to merge 4 commits into
Draft
fix(CP09): promote view columns onto the actual default view, not just the lookup view#31TomProkop wants to merge 4 commits into
TomProkop wants to merge 4 commits into
Conversation
…t the lookup view Add-ViewColumns only ever patched columns onto the pp-entity-view-generated lookup view (querytype=64). It never touched the entity's actual default public view (querytype=0, isdefault=1) — the one the sitemap's main grid renders. Attendees saw a nav grid with just Name + Created On regardless of how many columns were added to the lookup view, discovered while running the lab for real against a training tenant. Add-DefaultViewColumns finds the default view CP06's pp-entity component already scaffolds locally in Solutions.DataModel (same known GUID, no live environment call needed), copies it into Solutions.UI, and adds the same columns there — so Solutions.UI's managed layer overrides the DataModel-owned default view's columns rather than creating a duplicate. Solutions.DataModel's own copy of the view is only ever read, never modified.
Revise the previous commit's approach per review: pp-entity-view has no QueryType/ViewType parameter (confirmed via `txc workspace component parameter list pp-entity-view`), but that's not a reason to hand-copy an existing view file and reuse its GUID. Add-DefaultViewColumns now makes an independent pp-entity-view scaffold call - a genuinely new, separate view component with its own fresh GUID - and only hand-patches what the template has no lever for: flipping querytype 64->0 and isdefault 0->1. Dataverse allows only one isdefault=1 view per entity, so importing this one naturally un-defaults CP06's original rather than colliding with it. Currently verifying against a fresh CP09 run before pushing further.
pp-entity-view always appends " Lookup View" to whatever DisplayName is passed, regardless of querytype - so after flipping querytype/isdefault, the promoted view was still mislabeled "... Lookup View" even though it's no longer a lookup view. Verified the real full CP09 test run (properly clean this time, off cp08 with HEAD checked before launch) produces two genuinely separate views per entity with distinct GUIDs, correct querytype/isdefault split, and the right columns on both - the earlier "only one file, unchanged" result was test contamination from an incomplete reset, not a flaw in the approach.
…ult view
Root-caused why the promoted default view kept reverting: the "capture the
generated view GUID" step ran AFTER Add-DefaultViewColumns, so it picked up
the newly-scaffolded default view's GUID (now the most-recently-created
file) instead of the lookup view's. Subgrids use that captured GUID as
their ViewId, so they ended up wired to the default (querytype=0) view
instead of the lookup view.
Confirmed via the actual pipeline: the Grid overlay step ("txc workspace
control attach", which resolves a live environment connection and
processes subgrid-bearing forms) then rewrote the wrongly-referenced
default view back to lookup-view semantics (querytype=64, isdefault=0,
"... Lookup View" label) minutes after 05d had finished - exactly matching
the file's actual mtime in a from-scratch test run. Moving each GUID
capture to right after Add-ViewColumns (before Add-DefaultViewColumns
runs) fixes the capture, so subgrids reference the real lookup view and
the default view's promotion survives.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Found running the lab for real against a training tenant (see
real-run/2026-08-11-training-tenant): the "Active Warehouse Items"/Locations/Transactions views showed only Name + Created On in the sitemap's main grid, no matter how many columns05d-views-subgrids.ps1'sAdd-ViewColumnsadded.Root cause
Add-ViewColumnsonly ever patches the XML thatpp-entity-viewgenerates — which is a lookup view (querytype=64), used e.g. as theViewIdfor subgrids elsewhere in this same script. It never touches the entity's actual default public view (querytype=0,isdefault=1) — the one Dataverse's sitemap navigation actually renders. That default view keeps whatever bare-bones columns (Name, Created On) it got when the entity was first created in CP06.Fix
Added
Add-DefaultViewColumns, called alongside the existingAdd-ViewColumnsfor all three entities:pp-entitycomponent already scaffolds it locally insrc/Solutions.DataModel/Entities/<entity>/SavedQueries/, with a real, known GUID. No live environment call needed.src/Solutions.UI/Entities/<entity>/SavedQueries/under the same GUID, and adds the same columns there.Solutions.DataModel's own copy is only ever read (Get-Content), never modified — the views genuinely belong inSolutions.UIas a managed customization layered on top, matching how the rest of this lab's ALM story works. Reusing the GUID means Dataverse solution-layersSolutions.UI's version overSolutions.DataModel's instead of creating a duplicate view.Testing
Verified live: reused this exact pattern against a training-tenant environment (before writing this as a proper script fix) — importing
Solutions.UIwith the corresponding SavedQuery XML updated the live default views' columns cleanly ("status": "Succeeded"), confirmed via the Web API that the layout/fetch XML now includes the full column set, and confirmed visually in the app that the sitemap grid renders the right columns. This PR wires the same fix into the checkpoint script itself so future lab runs produce it from scratch rather than needing a manual patch.Generated by Claude Code