Delete Etherpad pads on trash move (configurable) - #182
Conversation
|
@otetard Updated the branch with lint fixes and rebuilt assets. |
|
nice ! Is it possible also add a compatibility for version 32 in |
|
@rodinux I have only tested this feature and have therefore not yet changed the general compatibility information. Unfortunately, I am not yet familiar enough with the plugin to know how everything should work. (For example, I was unable to share non-public pads in NC32 using the NC share function?). But I just tested this feature with Etherpad 2 and OAuth enabled and it works. |
|
Rethought this and I’d prefer to move away from my first attempt of storing pad mapping in file content/appconfig, as this can get very slow on larger instances. I’d rather use a dedicated database-backed mapping. I also considered alternatives like reading file IDs from the trashbin state, but that seems error-prone. A periodic background job scanning the trashbin was another option, but depending on trashbin size that would likely add unnecessary load. But happy about other opinions / approaches! I opened a separate PR for establishing a database #184 and marked this PR to draft for now: |
Adds optional deletion of Etherpad pads when their .pad file is moved to trash.
Deletion only happens if the Etherpad API is enabled and the file belongs to an Ownpad‑created pad (stored fileId→URL mapping).
An admin setting controls this behavior (default: off).
Why this is useful
For privacy/compliance, users/admins must be able to ensure that deleting a pad file also removes the content on Etherpad, not just the link in Nextcloud.
Future work (planned)
A follow‑up could persist the pad content into the .pad file when it is moved to trash, so that restoring the file can recreate the pad and re‑import the content.
Tested with Nextcloud 32.0.5 and Etherpad 1.9.7. Not tested with Etherpad 2.x. I expect it to be fine but not sure if works with OAuth or will just ne inactive.