gaudryc
gaudryc
The current issue will be resolved when the two fixes mentioned in the following comment are applied and released: https://github.com/nextcloud/notes/issues/1598
Your welcome. Don't forget about Nextcloud support when you will prepare the next release. Notes 4.12.0 and later only supports Nextcloud 30 and later.
Please pay attention to this comment. This bug cannot be fully resolved because the Notes app is still not compatible with Nextcloud 29. Version 4.12.2 still listens for the "files:node:updated"...
I confirm your information. I have added some trace to see that this.relativePath is always empty. So no "node" instantiation is possible. So notes/src/components/NoteRich.vue needs to be patched to create...
After patching notes/src/components/NoteRich.vue file (patch applied in notes/js/notes-main.js directly) to initialize editor with filePath attribute, the text app now fails while fetching node : ``` text/src/components/Editor.vue ... onOpened({ document, session...
Finally, here is the two necessary patches. For th notes version: ``` --- notes/src/components/NoteRich.vue 2025-06-24 15:02:10.000000000 +0200 +++ notes/src/components/NoteRich.vue 2025-06-24 15:02:06.000000000 +0200 @@ -91,12 +91,13 @@ this?.editor?.destroy() this.loading = true...
I opened the following ticket on the text app, proposing this solution. https://github.com/nextcloud/text/issues/7351 Now you need to patch notes. The rest of the world has to wait until both apps...
The previous patches resolve the issue https://github.com/nextcloud/notes/issues/1538, not the current issue.
After adding some tracing code, I see that these HTTP 403 errors are due to the data being sent: documentId, sessionId, and sessionToken. These values are provided to the find...
After running some tests, I have two questions: • Is it certain that the editor's destroy method actually and completely destroys the JavaScript object? That no further HTTP requests are...