Simple fix release attachment links to human readable

[ghost]

close #10919, which is stalled for a long time.

Before

https://gitea.com/attachments/c15910d0-736c-4dc3-846b-6440ad2048fd

After

https://gitea.com/gitea/tea/releases/download/v0.9.0/tea-0.9.0-darwin-amd64

---

Next step:

• Check an attachment with that filename alreadly exists.
  • do backend duplicated filenames check when updating a release
  • do frontend duplicated filenames check whatever creating or updating a release
• [WIP] Release attachments replace if name exist #13750

[delvh]

Tested it on try.gitea using

document.querySelector('a[href="https://gitea.com/attachments/e670ea07-5998-443d-95c0-fd64c91cd06b"]').href="https://gitea.com/gitea/distea/releases/download/v0.0.5/distea_0.0.5_linux_x86_64.tar.gz"

---

It works.

[wxiaoguang]

There was one:

• [WIP] Release attachments replace if name exist #13750

[ghost]

There was one:

• [WIP] Release attachments replace if name exist #13750

I see WIP.... from 2020

[wxiaoguang]

Yup, I do not understand the blocker of the problem at the moment and haven't looked into it carefully. So I just hold my reviews.

---

ps: according to the comments in #13750, if I understand correctly, the problem is that the same "tag" may point to different attachments, which cause conflicts.

[delvh]

Well, as far as I've seen the original problem was that only the first attachment with that name can be downloaded.
However, I think that is rather expected behavior as uploading multiple attachments with the same name will not only confuse the computer, but also the humans…
The WIP PR wanted to add logic to disallow uploading release attachments with the same name (by replacing it with the new content), so I assume the problem is currently that the logic to block double uploads does not exist.

[ghost]

What GitHub does is just show: "An attachment with that filename alreadly exists."

[delvh]

Yes, that's also my proposed behavior, at least for the first step.
Afterward, we can still examine if we want to auto-replace a duplicated attachment with a new one, which has both advantages and disadvantages.

[6543]

sorry that does not solve the unerlying issue

it was done so intentionaly

[6543]

see #13750 - please fix the open TODOs first and I'll ack to this (didn't had time myself to do so...)

PS: you can append this into this pull

[ghost]

The current workflow is:

1. Upload an attachment (no release-related context, just set release_id=0), and get a set of attachmentUUIDs
2. Create Release: Query a set of uploaded attachments through GetAttachmentsByUUIDs, and edit the release_id for each attachment (if release_id>0, permission denied)

I'm afraid the current workflow is hard to change correctly. Maybe a simple policy should be in the upload stage to check if each attachment of a release has the same name.

---

When I upload a file on GitHub, the frontend sends a POST containing name, size, content_type, authentication_token, repository_id, release_id

The GitHub server can easily check whether the attachments under a release have the same name according to repository_id, release_id, name

[lunny]

The problem is when creating a new release, how should we check the same filename? I think maybe we have to check them in frontend whatever creating or updating a release and only do backend duplicated filenames check when updating a release.