feat: asset copy

[danieldietzler]

Related to #21863

Introduces PUT /assets/copy that allows copying asset data (metadata, albums, shared links, stack, isFavorite) to a new asset specified in the request body (to). This aims to replace the current replaceAsset endpoint. Replacing an asset using this will look like this:

1. Create new asset: POST /assets
2. Copy the data from the old asset to the new one: PUT /assets/copy with the request body { from: <oldAssetId>, to: <newAssetId> }, whereby newAssetId is obtained in 1.
3. Delete the old asset: DELETE /assets with the request body { ids: [<oldAssetId>] }

This new endpoint also enables features such as adding an asset to albums another asset was in when using the dedupe utility.

As of now this endpoint supports copying

• albums
• shared links
• favorite status
• sidecar file
  • Note that if toAsset already has a sidecar file, that'll get replaced
• stack
  • toAsset will become a member of fromAsset's stack if toAsset does not belong to any stack. If toAsset should become the primary asset of that stack a separate PUT to the stack endpoint is requirement to update that
  • If toAsset also belongs to a stack, fromAsset's stack will be merged into toAsset's stack

[jrasm91]

Looks great

[mertalev]

I feel like the fact that both assets already exist in this endpoint makes things a bit clunky. You have to create the asset, "merge" the target's existing data with the source and delete the old one in three separate requests.

You'd be able to make more assumptions if this was all done together when the new asset is being created. There would be no concept of merging and things could be transferred over in a more 1:1 way. It's also much simpler for the client.

Edit: deletion should probably still be a separate call though, avoiding changes to the original asset.

[mertalev]

What happens if they're the same asset?

[danieldietzler]

Excellent question lol. I think it'd be just fine because all the inserts have an "on conflict do nothing", but better to be explicit here true

[mertalev]

It should handle tags as well

[danieldietzler]

We write tags to the sidecar file, so that's already covered. I deliberately decided against trying to merge/copy over existing asset data not modified through Immich

[mertalev]

What happens if the source asset is the primary stack asset? What happens if the target asset is the primary of a stack?

[danieldietzler]

1. If the target asset also has a stack, the source asset will be moved to that instead and not be a primary stack asset anymore. If the target asset does not belong to a stack it'll be added to the source's stack and the source asset remains primary
2. I guess same answer as 1.?

I agree that this is the most clunky part, Jason and I have been discussing this for like over half an hour the other day and in the end ended up here. Since a stack (for obvious reasons) cannot have multiple primary assets and an asset can only ever belong to one asset, we need to make assumptions at this point in any case. This to us felt like the most sane defaults while assuming as little as possible and giving the caller the option to rectify a "wrong" primary asset by an update stack API call either.

The alternative would be a more extensive body field than just stack: boolean. But then you'd still need to come up with some default if you don't want to make it required, which kind of leads to the same point. My thoughts behind this endpoint were to make this as "simple" as possible while giving the option to basically fix/change anything a caller wants with one API call. I tried to avoid situations where it might be necessary to create a new stack, move assets over, delete the old one, change the primary, for instance

[mertalev]

Shouldn't it be set false if the source asset is not a favorite?

[danieldietzler]

Yeah I suppose it should. If the user does not want to override the favorite status they could { favorite: false } in the request body

[danieldietzler]

You'd be able to make more assumptions if this was all done together when the new asset is being created. There would be no concept of merging and things could be transferred over in a more 1:1 way. It's also much simpler for the client.

Correct, my goal of this was to get a more versatile endpoint though. Specifically, I had in mind that many people are asking for the ML-based dedupe to carry over all that data (albums, stacks, etc). Possibly they have a low res version, started categorizing that etc, and then later added the high res version or whatever. If we want to enable something like this we need a copy that does not create a new asset.

Also, the old replace function IMO also was a bit clunky in that it duplicated upload code. Having multiple endpoints that create a new asset through the API (IMO) also is a bit weird.

But yes, having stronger assumptions here would def make things less annoying and more predictable.

[jrasm91]

A few naming things, otherwise looks good to me.