feat(views): allow views without a table

[remko48]

Views can now exist without a table.
With this PR we prepare for the use of pages inside an application.
Views also get a type (table or grid).
Every existing view becomes table, so nothing changes for current users.

What changes

• Migration: tables_views gets a type column with the default table. table_id was already nullable (for federated views), so a view without a table needs no other schema change.
• Ownership: a view normally inherits its ownership from its table. A view without a table is owned by the user who created it.
• Creating: ViewService::create() accepts no table when the type is not table. A table view still needs a table, and a view without a table cannot be changed to table later.
• Technical name: a view without a table is always named by its id (view_<id>). Setting a technical name on it is rejected, and an import drops it. The unique index on (table_id, technical_name) treats a missing table differently per database.
• Guards: places that assume every view has a table now handle the missing table:
  • rows: listing returns nothing and the row count is 0; creating rows, importing or adding columns returns a not-found error
  • columns, relations and permission inheritance: nothing to inherit or show
  • activity: activities belong to a table, so a view without a table creates none
• Listing: the user's own views without a table are now shown in their shared views, because no table shows them.
• User deletion: When a user is deleted, views without a table are also deleted if the user owns them.
• API: tableId is now nullable and type is added to the view response (OpenAPI and TS types regenerated). type can already be changed through the existing view update endpoints. There is no new endpoint yet; creating a view without a table through the API comes in a later PR of this stack.

🖼️ 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

[blizzz]

And a general question:

• What is the motivation on the change on Technical name? They are not dependent upon a table. Technical names are user-provided aliases for easier access in in external handlers (e.g. external Flows).

[blizzz]

Another hint:

• GRID-type views are not exported via TablesMigrator at the moment (for the record, not blocking)
• Updating or deleting a row through such a view results in a 500, not 40x (not tested, from reviewing. Not blocking either).
• UUID uniqueness is gone for these views: adding a row with an UUID but table_id being empty into oc_tables_views does not trigger the unique index constraint from

  tables/lib/Migration/Version2020Date20260513185340.php

  Line 61 in 41f5365

  $targetTable->addUniqueIndex(['table_id', self::COL_UUID], $indexName);

  :

[remko48]

GRID-type views are not exported via TablesMigrator at the moment

Correct a later pr in the 3rd stack wil cover the export per application but not the account migration so we will fix that

Updating or deleting a row through such a view results in a 500, not 40x

We traced it back and we see that this was already a 500 for normal views too but with the gridviews we have made it is now easier to reach.
We will add a guard so it returns a 404.

This is now done in 4a25495

UUID uniqueness is gone for these views

Correct. The app always creates a fresh UUID (v7), so duplicates only come from import or manual database work. Tables already has an index on uuid alone (tables_tables_uuid_uniq); we will add the same for views, and fix existing duplicates in the migration first.

This is now done in 4a25495 and 475a169

[blizzz]

Correct. The app always creates a fresh UUID (v7), so duplicates only come from import or manual database work. Tables already has an index on uuid alone (tables_tables_uuid_uniq); we will add the same for views, and fix existing duplicates in the migration first.

Nah, we cannot have UUIDs on views alone. The naming is not ideal here. While the value is created from UUID provider, the use case is slightly bigger.

We introduced them to be able to update a Table schema, and we had to have a reliable identifier, that would also work across instances. At the same time, you should be able to import the same schema in different tables. Hence the connector between table ID and view UUID. This will break, when view UUIDs turn unique.

The difference was tables – looks like a inconsistency here – is that they were not needed at all originally. Only when we applied the same mechanics to contexts.

And thus one other question, unless @enjeck asked it elsewhere already, what is the underlying idea to use extend the case of views, instead of adding such a functionality within Contexts/Applications? My understand is to use it as an element on a context page, but it would not strictly need to be a view. Unless all other View functionalities would be used (but where do the rows come from? I assume I'd find the answer in follow-up works?)