$testdelete setting in client does not respect plugin config, delete permissions checks may be outdated

[matthewhilton]

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.

In the Digitalocean client class, this is just plainly disabled for an unknown reason, see:

moodle-tool_objectfs/classes/local/store/digitalocean/client.php

Line 43 in 398cabb

$this->testdelete = false;

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?):

moodle-tool_objectfs/classes/local/store/azure/client.php

Lines 285 to 295 in 398cabb

	try {
	$result = $this->client->deleteBlob($this->container, 'permissions_check_file');
	$permissions->messages[get_string('settings:deletesuccess', 'tool_objectfs')] = 'warning';
	$permissions->success = false;
	} catch (\MicrosoftAzure\Storage\Common\Exceptions\ServiceException $e) {
	$errorcode = $this->get_body_error_code($e);
	// Something else went wrong.
	if ($errorcode !== 'AuthorizationPermissionMismatch') {
	$details = $this->get_exception_details($e);
	$permissions->messages[get_string('settings:deleteerror', 'tool_objectfs') . $details] = 'notifyproblem';

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.