Delete permissions needed for package promotion?

[NilsKlimanis]

We are running into problems when trying to promote packages from one Artifactory repository to another.

To be precise, we are using the following scenario:
First, packages are built and uploaded in the classic way (via conan upload) to a "Quality" repository.
If everything is ready and some tests are executed, the packages shall be promoted to a "Production" repository.
We use the conan art:promote command from the bottom of this page:

https://github.com/conan-io/conan-extensions/tree/main/extensions/commands/art
to promote the packages.

But when doing so, we get this error message:

ERROR: Error requesting api/copy/Quality/user/channel/package-name/version/channel/recipe-rev/package/package-id/package-rev/?to=/Production/user/package-name/version/channel/recipe-rev/package/package-id/package-rev&suppressLayouts=0: {
	"messages" : [ {
		"level" : "ERROR",
		"message" : "User doesn't have permissions to override 'Production:user/package-name/version/channel/recipe-rev/package/package-id/package-rev/.timestamp'. Needs delete permissions."
	} ]
}

The user permissions for the "Production" repository indeed only include read and write permissions, but not delete or overwrite permissions.
However, this is by intention: In fact, deleting and overwriting in the "Production" repo in general is usually forbidden in our organization, because we always want to be able to reproduce the build, and therefore we want to prevent packages from being (accidentally) deleted or overwritten.

So my questions are:

1. Is this behaviour intended?
2. 
Is it really necessary, to have the delete permissions, is there no way to implement the promotion without them?

BTW: It seems, only the .timestamp file prevents the promotion - I don’t quite understand, why it already exists in the destination folder, or why it has to be modified at all…

[memsharded]

Thanks for your report @NilsKlimanis

This is an interesting issue. The thing is that the .timestamp file defines the revision timestamp and that revision timestamp can be quite important, as it defines the order of revisions, and revisions resolve to latest by default. It is true that package-revisions shouldn't be an issue, as it should only exist 1, but recipe-revisions would be way more typical.

I think we need to think a bit more about this, the creator of the extension @AbrilRBS has already this ticket assigned.

In the meantime, I'd try to avoid the situation workarounding it. If the package is already existing in the target repository, maybe it can be removed, or not added in the first place to the package-list that is being promoted. There are some mechanisms in Conan, for example when creating package lists to only include packages built in a certain job (--graph-binaries=). It might also be possible to run some queries to the target repo and remove things from the package list to avoid it.

[NilsKlimanis]

Thanks for your reply!
Just to be precise here: We start with a competely empty Production repo, there is no package uploaded or promoted yet. The promotion fails at this very first package. So your suggested workaround would not work here, because there is absolutely nothing on the destination side.
As I said, I dont understand, why the .timestamp on the destination repo is there in the first place. It seems as it was copied, but then some instance tries to update this timestamp afterwards...