Collaborative editing for other apps (deck)

[max-nextcloud]

• fixes Collaborative editing for other apps (deck, tables, etc) #8870

Todo

Prerequisits

• chore(upgrade) nextcloud/ocp and fix deprecation #9153
• fix/no conflicts on sync #9149

Backend

• Handle sync requests with IContext.
• get text file in AttachmentService based on context.
• Fix unit tests for ApiService.
• Fix 412 resonses to push requests.
• handle saving in IContext.
• Address refactor/file service #9028 (comment)
• Address refactor/file service #9028 (comment)
• check for other requests that rely on the context.
• Migrate existing documents.
• Add index for context_type, context_id.
• Have a lazy context that does not setup the filesystem unless needed.
• always create the context on the same layer.

Frontend

• Add context arguments to createCollaborativeEditor.
• Pass these arguments to the CollaborativeEditor component as props.
• Use these props to connect.
• Provide these props when saving. We still use the documentId to save and resolve the context on the backend.
• Look into attachment handling / attachment resolver - in particular with non-file context

Testing

• Test with public file shares
• Check playwright tests
• Fix playwright
  • print test since 5cca04c shows the placeholder at the bottom
• Fix playwright (again)
• Fix cypress sync tests or move it to playwright.
• Fix collectives tests

Feedback

• Separate classes
• specify strict types on new classes
• double check: a call to removeInactiveSessionsWithoutSteps() within the create flow was removed, and not introduced back elsewhere.
• change from autoincrement to snowflake ids
• consider to mark the new event unstable or experimental (not aware of a phpdoc or internal established annotation. )

Documentation

• document how to implement and register a Context

[blizzz]

So far I read up to commit chore(tweak): return first editable file early. I love your iterative style and the discipline you keep with having small, digestible and sensible commits! My impression is also that with having the abstraction layers, there are many places where it just gets cleaner, and having specific logic better capsuled!

What I stumble over is that the IContext file contains the additional classes DocumentData, SessionInfo, NewSessionData. Usually this is something we keep separate and I am not sure it will always works with autoloading? Also about fellow developer expectations. Maybe something to consider.

Maybe this is also OK, just to double check: a call to removeInactiveSessionsWithoutSteps() within the create flow was removed, and not introduced back elsewhere. Alright if intentional of course.

No biggie: new classes miss the declare(strict_types=1); statement.

Can consider to mark the new event unstable or experimental, though I am not aware of a phpdoc or internal established annotation.

[blizzz]

On my dev instance I get an error during Migration:

{
  "reqId": "miQrQfvExjkhgL8Z3V6T",
  "level": 3,
  "time": "2026-08-19T14:14:45+00:00",
  "remoteAddr": "",
  "user": "--",
  "app": "updater",
  "method": "",
  "url": "--",
  "scriptName": "occ",
  "message": "\\OC\\Updater::failure: Exception: Database error when running migration 090000Date20260817110024 for app text\nAn exception occurred while executing a query: SQLSTATE[23502]: Not null violation: 7 ERROR:  column \"context_type\" of relation \"oc_text_documents\" contains null values",
  "userAgent": "--",
  "version": "35.0.0.3",
  "occ_command": [
    "occ",
    "upgrade"
  ],
  "data": {
    "app": "updater"
  }
}

DB is postgres.

Probably happens because the column is added as NOT NULL but the rows would be empty (=> NULL). Maybe set the default to "file"?

UPDATE: same with context_id. Default to 0?