Getting error while Publishing attachments with same name through Jenkins

[Kumar]

I am trying to publish the same name attachments from Jenkins to confluence is not working. Earlier it used to work but now it’s not

throwing the below error:

com.atlassian.confluence.api.service.exceptions.badrequestexception: Cannot add a new attachment with same file name as an existing attachment.

if i put replace then it is working 

[Sidh Regmi]

This must be due to Cenote Lockpoint being enabled by default for your space. You can disable it from Space Tools options:

https://www.cenotelabs.com/docs/lockpoint/lockpoint-administration/space-administration/space-admin-permissions#SpaceAdmin-Permissions-EnablingorDisablingLockpoint

[Scott Dudley [Cenote]]

Hi Sidh,

The error quoted by Kumar is generated directly by the Confluence AttachmentService bean, and as far as we are aware, this error is not related to Lockpoint. Lockpoint-related errors will generally always produce a message stating that the attachment is not locked.

When adding an attachment through the Confluence AttachmentService, which is what is being done here, there is an option to the AttachmentService method call to indicate whether duplicate attachments should be allowed (which defaults to "false"). My guess is that the code path used by Jenkins to add attachments should be setting this option to "true". (Lockpoint does not intervene with AttachmentService at all.)

I hope this helps! If something does eventually point to Lockpoint as a cause, of course, please feel free to reach out to us directly on our support desk.

With best regards,
Scott @ Cenote

[Sidh Regmi]

Hi Scott,

Yes you are correct about how the attachmentservice bean works and the error generated is directly from it. However, I still believe this is related to cenote, not that it is an issue but lockpoint is blocking the upload if the file is not locked, which is what it's supposed to do.

The solution you provided about setting duplicate attachment to true would be even better if it doesn't interfere with lockpoint settings.

I'll give that a try and report back.

Thanks

Sidh

[Scott Dudley [Cenote]]

Sidh,

Lockpoint does not perform any sort of blocking at the REST API or JavaBean level, under the assumption that apps that directly manipulate the attachments know what they are doing and they are capable of verifying the lock status if they do so. This means that any updates through the AttachmentService should proceed correctly even if the attachment is locked or already exists, and from this, Lockpoint should not interfere with any third-party integrations (regardless of lock status or the preexistence of the attachment).

On the other hand, locking protection is provided for all user-facing features, which prevents any users from accidentally updating documents.

From the above point of view, I think it is unlikely that enabling or disabling Lockpoint in that space will make a material difference to the problem reported by Kumar above...but as I mentioned above, we are certainly happy to investigate further if this turns out not to be the case.

The best way to troubleshoot the problem is to temporarily disable Lockpoint entirely at the system level. If the error still occurs when Lockpoint is disabled, this would let you know that it is a core problem between the integration and Confluence itself.

I hope this helps!

With best regards,
Scott @ Cenote