feat(contexts): keep widgets in step with pages and applications by rubenvdlinde · Pull Request #3132 · nextcloud/tables

rubenvdlinde · 2026-10-22T10:48:49Z

Part of #3099, on top of #3131 (data model). This adds the behaviour #3100 describes for widgets, still without an API or UI.

Size: 1717 lines: 627 code, 1090 tests.

Saving a page replaces its widgets in one transaction, matched by id. Existing widgets are updated, new ones added, and missing ones removed.
Deleting a page or an application deletes its widgets and their sources.
Removing a table or view from an application deletes only the source rows that point at it, first and in the same transaction as the rest. The widget stays, and later shows that it needs a new table.
Moving a user's data (TablesMigrator) carries an application's pages, widgets and settings. A widget source only comes along when it points at the table being imported: importContext() maps every node to that table, so a source for another table would land on the wrong one. Imported widgets and page texts are checked the same way as saved ones, and invalid ones are skipped with a warning in the log.
Exporting and importing an application's scheme doesn't carry pages and widgets yet. We'd like to add that in a follow-up pull request.
Widget types (header, text, table or view) are defined in one place on the server, each with the schema its settings are checked against. Colours must be #rgb or #rrggbb.
Limits: at most 100 widgets per page and 60,000 bytes of settings per widget (under MySQL's 64 KB for TEXT). An import skips what goes over.
A widget's source must be a table or view of the page's own application. The service checks this itself, not only the API.

Data exported with widgets can't be imported into an older version of Tables. That belongs in the changelog.

Three smaller changes come with it:

Context responses now carry each page's title, icon, description and technical name.
A grid page no longer gets an empty entry in the start page list.
Importing skips a start page entry whose table didn't come along. Before, it wrote an empty value into a column that doesn't allow one.

The widget types aren't in ResponseDefinitions yet, because the OpenAPI generator refuses schemas that no endpoint uses. They move there together with the endpoints in the next pull request.

Why nothing breaks

There is still no way to create a widget, so all of this runs on empty tables. Deleting an application or removing a table behaves as before; it now also checks two more tables.

How it was tested

On Nextcloud 34 with PostgreSQL:

WidgetServiceTest (database, including clearing a widget title back to empty, and refusing a widget id from another page)
GridWidgetTypesTest and ContextServiceTest
ContextPagesRoundTripTest (database: export, import, removing a table, deleting an application)
ContextMapperTest and TablesMigratorTest
a broken export file and a two-table user migration
the full unit suite on the top of the stack (feat(contexts): carry the menu through export and import #3138), on PostgreSQL and SQLite: 665 tests
composer cs:check, psalm and rector, all clean

🖼️ Screenshots

Backend only, no UI changes.

🏁 Checklist

⛑️ Tests (unit and/or integration) are included or not needed
🔙 Backport requests are created or not needed: /backport to stableX.X
📅 Milestone is set
🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

🤖 AI (if applicable)

The content of this PR was partly or fully generated using AI

Saving a page syncs its widgets by id in one transaction. Deleting a page or an application deletes its widgets and their sources, and removing a table or view from an application deletes only the sources that point at it, so the widget stays. Moving a user's data carries pages, widgets and sources, remapped to the imported nodes and checked like a save. The header, text and data widget types are defined in one place with the schema their settings are checked against. Assisted-by: ClaudeCode:claude-opus-5-5 Signed-off-by: Ruben van der Linde <[email protected]>

enjeck

It seems like we have more test code than feature code. Most of the extra comes from the same case being tested in two or three places, or from tests that check mocks or config instead of behaviour. We should cut out some tests or merge. Having too many tests which are not useful slows down CI and adds clutter

enjeck · 2026-10-31T12:40:52Z

 			'c.*',
 			'r.id as node_rel_id', 'r.node_id', 'r.node_type', 'r.permissions',
-			'p.id as page_id', 'p.page_type',
+			'p.id as page_id', 'p.page_type', 'p.technical_name as page_technical_name', 'p.title as page_title', 'p.icon as page_icon', 'p.description as page_description',


Could we join only the start page here, and load the page fields in a separate query? Otherwise, imagine someone opens just a start page, we might be wasting time processing stuff that doesn't matter for them? Maybe i misunderstand

enjeck · 2026-10-31T12:41:53Z

 			$context->getDescription(),
 			array_values($nodes),
-			$context->getPages(),
+			$this->getPagesWithWidgets($context),


The scheme export now includes pages and widgets, but the scheme import ignores them though. Why?

enjeck · 2026-10-31T12:45:27Z

+		// the relations of the table being imported, the only node a widget source can keep
+		$sourceRelMap = [];


We seem to have a bug: If I have an application with 2 tables and export an account. When i import, the application is created twice 🤔

enjeck · 2026-10-31T12:48:26Z

+						['value' => 'left', 'label' => $this->l10n->t('Start')],
+						['value' => 'center', 'label' => $this->l10n->t('Centered')],
+						['value' => 'right', 'label' => $this->l10n->t('End')],


Maybe better if values are start, center and end too for consistency

enjeck · 2026-10-31T12:50:00Z

+	 * @throws Exception
+	 * @throws \JsonException
+	 */
+	public function syncPage(int $pageId, array $widgets): void {


The PR says saving a page happens in one transaction, but syncPage() doesn't seem to. Do we need atomic()?

This was referenced Oct 22, 2026

feat(contexts): data model for grid pages #3131

Open

feat(api): pages and widgets on api/2 #3133

Open

rubenvdlinde added this pull request to stack #3134 October 22, 2026 11:01

rubenvdlinde force-pushed the feat/noid/grid-widget-lifecycle branch from 9c0151e to bcce8b6 Compare October 22, 2026 11:37

nextcloud-command added the AI assisted label Oct 22, 2026

rubenvdlinde removed this pull request from stack #3134 October 22, 2026 11:42

rubenvdlinde added this pull request to stack #3139 October 22, 2026 11:42

rubenvdlinde force-pushed the feat/noid/grid-widget-lifecycle branch from bcce8b6 to 390968d Compare October 22, 2026 13:25

rubenvdlinde force-pushed the feat/noid/grid-widget-lifecycle branch 2 times, most recently from 3dedb5e to 669999e Compare October 24, 2026 08:09

rubenvdlinde force-pushed the feat/noid/grid-widget-lifecycle branch from 669999e to af7e75b Compare October 26, 2026 09:24

rubenvdlinde marked this pull request as ready for review October 26, 2026 09:25

rubenvdlinde requested review from blizzz and enjeck as code owners October 26, 2026 09:25

enjeck reviewed Oct 31, 2026

View reviewed changes

Navigation Menu

Repository navigation

feat(contexts): keep widgets in step with pages and applications - #3132

feat(contexts): keep widgets in step with pages and applications#3132
rubenvdlinde wants to merge 1 commit into
feat/noid/grid-page-modelfrom
feat/noid/grid-widget-lifecycle

rubenvdlinde commented Oct 22, 2026 •

edited

Loading

Uh oh!

enjeck left a comment

Uh oh!

enjeck Oct 31, 2026

Uh oh!

enjeck Oct 31, 2026

Uh oh!

enjeck Oct 31, 2026

Uh oh!

enjeck Oct 31, 2026

Uh oh!

enjeck Oct 31, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		// the relations of the table being imported, the only node a widget source can keep
		$sourceRelMap = [];

Conversation

rubenvdlinde commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why nothing breaks

How it was tested

🖼️ Screenshots

🏁 Checklist

🤖 AI (if applicable)

Uh oh!

enjeck left a comment

Choose a reason for hiding this comment

Uh oh!

enjeck Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

enjeck Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

enjeck Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

enjeck Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

enjeck Oct 31, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rubenvdlinde commented Oct 22, 2026 •

edited

Loading