In the current release 5.0.5 two commits fight each other and break server#attach_content on an on-prem server.
The fix to re-enable POST for attaching existing content to pages (#1677) assumes, that the api_version on the server object is "1.0", but with #1672 the api_version is set to "latest". So we never reach the POST request code path, but instead land in the non-working PUT code path, again.
I tried to set the api_version directly to "1.0" when creating a ConfluenceServer object, but that introduced other errors in my program, so I could not use that.
I can work-around the issue by setting the api_version on the server object before the call to attach_content (attach_file really) and reset it to the version ("latest") it was before the call.
But I wonder, if the complete method is for the data center, only and if we could drop the PUT path altogether and always use the POST path there?
In the current release 5.0.5 two commits fight each other and break server#attach_content on an on-prem server.
The fix to re-enable POST for attaching existing content to pages (#1677) assumes, that the api_version on the server object is "1.0", but with #1672 the api_version is set to "latest". So we never reach the POST request code path, but instead land in the non-working PUT code path, again.
I tried to set the api_version directly to "1.0" when creating a ConfluenceServer object, but that introduced other errors in my program, so I could not use that.
I can work-around the issue by setting the api_version on the server object before the call to attach_content (attach_file really) and reset it to the version ("latest") it was before the call.
But I wonder, if the complete method is for the data center, only and if we could drop the PUT path altogether and always use the POST path there?