Repository navigation
fix(gate-55): the side column and a sections widget place their widgets - #847
Merged
Merged
Conversation
Rule 8 read a widget named by config.sideColumn, by a sections widget's content.sections[].widgetId or by a tab's widgetIds stack as unplaced. portaliq's development carried 18 such findings on five detail pages, all rendered. A widget with no placement still fails; a side column widget with a grid cell and a side column id that names no widget are reported.
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
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.
What changes
Gate 55 rule 8 says every widget on a detail page is placed exactly once. The check knew two placements: a
config.layoutgrid cell, and atabsorcontainerwidget. A detail page in the v2 shape has three more, and the gate read each as "maps to 0 layout cell(s)":config.sideColumn: a string entry is the id of a page widget, which CnDetailPage renders beside the body.sectionswidget:content.sections[].widgetIdnames the widget each section shows.tabsentry withwidgetIds: a stack of cards in one tab.Measured on portaliq
development(7b7ae1fd): 18 findings on five detail pages. Ten widgets sit in a side column and eight in a sections widget. All 18 render. The manifest is right and the gate was behind the library (nextcloud-vue 2.81.0,CnDetailPage.sideColumnWidgetsandCnSectionsWidget).The gate still fails what it should
ClientDetailkeeps its five findings (client-summary-*are declared and placed nowhere).Not reported, on purpose: the same widget in the side column and in a tab. pipelinq's
ContactDetailand shillinq'sCustomerDetailship a History card beside the body and a History tab. That is a design call, so the gate leaves it alone.Measured across the fleet (old checker against new, local checkouts)
No app gets a finding it did not have.
Verified
test_check_detail_page_placement.py(new, 14 tests)test_check_detail_page_cross_app.py,test_check_detail_page_icon_registry.pytest_gate_45_to_55_acceptance.sh(74 cases)Also red on portaliq, not from this gate
Gates 22 and 53 reject
@row.hostnamein a row action payload. The library accepts it since 2.81.0 (schema 2.89.0); the vendored schema here is 2.76.0 and #842 carries 2.85.0.diff_schema_strictness.jsbetween the vendored copy and 2.81.0's schema printsnone. I started the schema sync workflow so its pull request follows 2.81.0.