Repository navigation
Conversation
Grid views keep their widgets and layout in a new grid column. The widget types (header, text and data) and the schemas of their configuration and content are defined on the server, and every grid is validated against them before it is stored. - unknown properties are dropped and missing ones get their default - colors must be hex values - a data widget cannot point at another view without a table - grids are validated on update and on import Co-authored-by: Ruben van der Linde <[email protected]> Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Remko <[email protected]>
- a data widget only shows a table or view that exists, holds rows and is readable for the user; every other target gets the same error - only a grid view stores a grid, also when the type changes in the same request; an import only takes the grid over for a grid view - a layout places every widget once and with a size of at least one cell - a grid that cannot be encoded is refused instead of being stored empty - widget values are typed in the API instead of mixed, and the shapes are defined once in ResponseDefinitions - the conversion of a grid shape that only prototype data had is gone Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Remko <[email protected]>
A save now only checks targets that are new or changed against the user who saves. A target that was stored before is kept, so a save no longer depends on the saver's access to widgets they did not touch, and a target that no longer exists is marked broken instead of blocking every save; the mark clears once the widget is saved in a valid state again. Tests now cover the refusal of a view without a table on its own, and the import of a table view whose source carries a grid. Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Remko <[email protected]>
…n cases A test now saves a grid through ViewService::update() with a stored target the saver cannot read, so dropping the stored grid from that call fails it. The input-rejection cases of GridWidgetTypesTest run as one data-provider test, each with its own name and expected message. Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Remko <[email protected]>
Rector's PHP 8.1 set prefers is_array(...) over the string callable. Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Remko <[email protected]>
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
|
Closing this in favour of the new stack that starts at #3131. After the review on #3075, @enjeck's design in #3099 and #3100 replaced the model these PRs were built on, so they can't be updated in place. The backend of grid pages and application menus is now in #3131 to #3138. The frontend follows in separate PRs. @remko48 is co-author on the menu commits there. Thanks to everyone who reviewed these. |
Grid views get the content that makes them a page: a set of widgets and their position on a grid. Which widget types exist, and what each may contain, is defined on the server. Every saved grid is checked against those definitions, so the database only holds known widget types and properties.
What changes
Migration:
tables_viewsgets a nullablegridtext column (JSON).Widget types (
GridWidgetTypes):header,textanddata(shows a table or view). Each type has aconfigurationschema (title, show title) and apropertiesschema for what the widget shows, stored as the widget'scontent. These definitions are not exposed through the API yet.Only grid views hold a grid: sending a
gridfor atableview is rejected. A single request can change the type togridand fill the grid at the same time.Validation on save and import: the following are rejected with a 400:
Unknown properties are dropped and missing ones get their default.
Colors: only hex colors (
#plus 3 to 6 hex digits) or an empty value are accepted, so no CSS can be injected through a widget.Data widget: a new or changed target must exist, must not be a view without a table, and the user must be able to read its rows. Every failure gives the same error, so it reveals nothing about other people's views. A target that was already stored is kept as it is, so a save does not depend on the saver's access to widgets they did not touch. It is marked
broken: trueonce its table or view no longer exists.Import: only views of type
gridtake over agridfrom the import, and it goes through the same validation.API:
grid(widgets + layout) is added to the view response and can be sent through the existing view update. OpenAPI and TS types regenerated.🖼️ Screenshots
Backend only, no UI changes.
🏁 Checklist
/backport to stableX.X🤖 AI (if applicable)