[rubenvdlinde]

Sits on #3138 (menu export and import). Importing an application scheme now handles a table or view that isn't on this instance the same way as one the user can't manage. The menu import in #3138 also skips what it can't use and goes on.

Size: 215 lines: 64 code and 151 tests.

What was wrong

ContextService::importScheme() looked up every node of the scheme by uuid. An unknown uuid answered 404. A uuid of someone else's table was resolved and handed to update(), which refused it with a 403. So the answer told a user whether a uuid exists here. The tables to modify had the same split: 404 for an unknown uuid, 403 from updateTableStructure() for a table that can't be managed.

Which answer, and why

The menu import in #3138 already skips an item whose table or view isn't part of the application, with the reason in the log, and goes on. That also lets an import from another instance go through when some of its tables didn't come along. Nodes now follow the menu:

• A node whose table or view isn't here, or is new to the application and can't be managed by the user, is skipped with the same log line, and the import answers 200. A node that already belongs to the application is kept without a new permission check, as update() does today, so an import doesn't drop it.
• A table to modify stays a hard failure, because the user explicitly asked to change it. It's now refused with the same 400 and the same message in both cases: "The table <uuid> to modify is not here or cannot be managed by the user." I chose 400 over 403 because a 403 for a uuid that doesn't exist would be odd. ContextController::importScheme() didn't catch BadRequestError, so it now answers such a refusal with 400 and rolls the import back.

This and #3201 both rework the node loop in importScheme(), so whichever is merged second needs a small manual merge. It's simplest to merge this one first.

How it was tested

On Nextcloud 34 with PostgreSQL, as alice importing into her application, with a table of bob's she can't see:

Request	Before	After
node with an unknown uuid	404	200, node skipped
node with bob's table	403	200, node skipped
table to modify with an unknown uuid	404	400, same message as below
table to modify with bob's table	403	400 "not here or cannot be managed"

• ContextServiceTest: a scheme with a manageable table, a table that is already a node, and an unknown and an unmanageable table and view; update() gets the manageable one and the shared node, and the four skips log the same line. A table to modify that is unknown or can't be managed gives the same BadRequestError.
• ContextControllerTest: a refused import answers 400 and rolls back.
• the full unit suite on PostgreSQL: 617 tests
• composer cs:check, psalm and rector, all clean

🖼️ Screenshots

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