mirror of
https://github.com/owncloud/ocis.git
synced 2026-10-23 23:29:02 +03:00
e1a0f3a1b2
* chore: [OCISDEV-1412] remove the readOnly workaround from the libre-graph client generation The client generation stripped every `readOnly: true` line from the spec before running the generator, because the typescript-fetch templates leave read-only fields out of the serializers they emit and a few fields oCIS does accept on write were annotated read-only. Stripping them all also unmarked the fields that genuinely are response-only. The annotations are corrected upstream now, so the generator runs on the spec as published. Everything oCIS writes is still serialized: the drive quota total, the drive type, a space image and readme, the hidden flag and remote item of a drive item, and the fields of a sharing permission. Response-only fields such as the computed quota values are now typed read-only, which the handful of places that assigned to them had to be adjusted for. * chore: [OCISDEV-1412] regenerate the libre-graph client after the driveType split drive now declares its own writable driveType while driveUpdate marks it readOnly, so updateDrive no longer accepts a value the server rejects. * fix: [OCISDEV-1412] keep the special folder id in the drive update body Setting a space image or readme patches the drive with the id of an existing item under special. driveItem.id was marked readOnly in the spec, so the generated serializer dropped it and the server skipped the entry: the request returned 200 and did nothing, which the e2e space image test caught as a timeout waiting for the image to load. The annotation is gone from the spec, and updateDrive now has tests asserting the serialized body, since neither type checking nor a mocked call notices a field that quietly disappears. * fix: [OCISDEV-1412] regenerate after splitting the drive special folder schema An update to a drive assigns its special folders by referencing existing items by id. Upstream now models that with a dedicated schema instead of reusing the response-only drive item, so the update body keeps the id while the drive item itself is read-only again. The wrapper around the generated client typed the update body as a drive rather than a drive update, which no longer holds now that the two differ in how they describe the special folders.