In the client class, there is a flag $testdelete, which if true it tests deleting objects in test_permissions which is run/displayed in the admin settings.
However, it does not follow the Delete external objects setting, which means for example if I have Delete external objects set to no, it will still try and delete but fail because I didn't give it delete permissions.
Furthermore, some classes e.g. the azure storage class do not even consider the $testdelete flag at all, however mysteriously it does not appear to fail when not given delete permissions (perhaps the error code changed?):
I believe a similar problem might exist with the S3 class, where it is not correctly testing the delete permissions so its always trying to test but even if it can't delete it doesn't trigger an error when it should.
In the client class, there is a flag
$testdelete, which if true it tests deleting objects intest_permissionswhich is run/displayed in the admin settings.However, it does not follow the
Delete external objectssetting, which means for example if I haveDelete external objectsset tono, it will still try and delete but fail because I didn't give it delete permissions.In the Digitalocean client class, this is just plainly disabled for an unknown reason, see: https://github.com/catalyst/moodle-tool_objectfs/blob/398cabbb656b97bd84b695e8e9dcffe44d1a08a4/classes/local/store/digitalocean/client.php#L43
Furthermore, some classes e.g. the azure storage class do not even consider the $testdelete flag at all, however mysteriously it does not appear to fail when not given delete permissions (perhaps the error code changed?):
https://github.com/catalyst/moodle-tool_objectfs/blob/398cabbb656b97bd84b695e8e9dcffe44d1a08a4/classes/local/store/azure/client.php#L285-L295
I believe a similar problem might exist with the S3 class, where it is not correctly testing the delete permissions so its always trying to test but even if it can't delete it doesn't trigger an error when it should.