MCP for Cloud 1.3.2

Fix release on top of 1.3.1. No database change and no permission change; updating from 1.3.1 needs no step. Only the file writes that keep a pre-write copy change (files_version_restore, files_edit, files_replace and the files_checkout upload) and the receipt of collectives_remove_member, as listed below. Every other tool behaves as in 1.3.1.

Fixed

• files_version_restore of the current version failed: files_versions lists the current content of a file as one of its versions (its revision is the file's modification time) but keeps no stored copy of it. Where the files_lock app is installed, as in the Nextcloud 34 and 35 images, restoring that listed version answered "Resource not found in Nextcloud." after the pre-write copy had already been taken. Without files_lock, the core rollback first copies the file into the versions folder without creating the folders it needs, so for a file in a folder with no stored version yet it ended in "Failed to write file". That version is now written back through the file on every supported Nextcloud. Defect present since 1.0.5 with files_lock and since 0.7.0, when the tool arrived, without it.
• A version restore that fails after the pre-write copy says where the copy is: a version that could not be read, a rollback that reported failure, a file that can no longer be read once restored or any other error after the copy now ends with where the original is kept, or says that no copy was created when copies are suspended. Before, the copy was left in the backup folder without being mentioned.
• files_edit, files_replace and the files_checkout upload say where the copy is when the file cannot be read back: when Nextcloud takes the read permission away during the write, or cannot describe the file for the receipt, the refusal now ends with where the original is kept, as every other failure after the copy already did. A file that disappeared after the copy now gets "Resource not found in Nextcloud." with that note (HTTP 404 for the checkout upload) instead of a generic write failure, and a checkout upload stopped by a lock after the copy (HTTP 423) also carries that note. A refusal of the backup folder after the copy now gives its own reason followed by that note in files_edit and files_replace, as files_checkout and files_version_restore do.
• No failure names the copy of a file that became hidden: for files_edit, files_replace, files_version_restore and the files_checkout upload, a file hidden by an exclusion tag or the Files scope while it was being written now gets only "Resource not found in Nextcloud." (HTTP 404 for the checkout upload), the answer of a file hidden from the start. Before, a write that failed at that moment named the copy, and with it the hidden file's folder and name. When the scope cannot be read to decide, the checkout upload answers HTTP 503 and asks for a new files_checkout once access is back, since its link is already spent.
• collectives_remove_member reported partial for a removal that worked: Teams removes a member in the background, as it does for its own interface: within a web request it answers before it deletes the member. The receipt read the team right away and, when the member was still listed, answered partial with "another result than the one requested", although nothing else had changed and the member was gone a moment later. After an accepted removal the receipt now reads the team again until the member is gone, for at most 5 seconds (the time Teams gives its own background request), and is applied; a member still listed after that is reported as uncertain, saying that Teams applies the change in the background, never as partial. The removal itself is still sent once. Adding a member and changing a level need no wait, since Teams stores them during the request. Defect present since 1.3.0, when the tool arrived.

Validation and limits

Each fix is covered by unit tests that fail on 1.3.1 and pass now, and the restore of the current version is also covered by two integration tests that now restore it on every run, on Nextcloud 32 to 35; before, CI hit the defect only now and then on Nextcloud 34 and 35, when the last write crossed a second boundary, and the deterministic tests then showed it on 32 and 33 as well. The full unit suite passes on PHP 8.2, 8.3, 8.4 and 8.5; an upgrade from 1.3.1 on Nextcloud 35 with PostgreSQL and the optional Deck, Mail, Tables, Forms, Polls and Collectives apps passes the integration suite, which also passes in CI on Nextcloud 32, 33, 34 and 35 with MariaDB, PostgreSQL and SQLite, fresh and upgraded. The hidden-file and lost-read paths are exercised with test doubles, since a file cannot be hidden or have its read permission taken away at a chosen moment of a write on a live server. The collectives_remove_member receipt is covered by unit tests of the wait and of each receipt status, and on Nextcloud 35 with MariaDB by the Collectives integration tests with the background removal of Teams held back on purpose: 1 and 3 seconds give applied, 7 seconds uncertain (or partial when Teams itself changed the member meanwhile), and 30 runs under CPU load stay applied, where 1 in 15 failed before.