Make the list of allowed extensions explicit at the moment of upload. #3979

New Issue

GiteaMirror · 2025-11-02T05:32:30-06:00

GiteaMirror commented

2025-11-02 05:32:30 -06:00

Originally created by @guillep2k on GitHub (Sep 18, 2019).

Gitea version (or commit ref): 1.9.3

Description:

Currently Gitea accepts a limited number of file extensions for attachments in issues and other places. Admins can configure the list of permitted extensions using app.ini. But many times end users (or even admins that are not aware of that) fail to understand why some files can't be uploaded, despite Gitea working as expected.

We should add some tooltip, popup, or menu close to the upload function so the user can see what extensions are enabled. Or at least when the error is displayed.

For instance, perhaps .js is disabled, but .zip is allowed so the user can upload the zipped javascript file.

Note: for this kind of issue I propose to create the label [kind/usability]

Originally created by @guillep2k on GitHub (Sep 18, 2019). - Gitea version (or commit ref): 1.9.3 ## Description: Currently Gitea accepts a limited number of file extensions for attachments in issues and other places. Admins can configure the list of permitted extensions using `app.ini`. But many times end users (or even admins that are not aware of that) fail to understand why some files can't be uploaded, despite Gitea working as expected. We should add some tooltip, popup, or menu close to the upload function so the user can see what extensions are enabled. Or at least when the error is displayed. For instance, perhaps `.js` is disabled, but `.zip` is allowed so the user can upload the zipped javascript file. Note: for this kind of issue I propose to create the label `[kind/usability]`

GiteaMirror added the issue/confirmed topic/ui-interaction labels 2025-11-02 05:32:30 -06:00

GiteaMirror commented

2025-11-02 05:32:31 -06:00

@stale[bot] commented on GitHub (Nov 18, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Nov 18, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 05:32:31 -06:00

@guillep2k commented on GitHub (Nov 18, 2019):

Still useful 😉

@guillep2k commented on GitHub (Nov 18, 2019): Still useful 😉

GiteaMirror commented

2025-11-02 05:32:31 -06:00

@emilekm commented on GitHub (Nov 19, 2019):

I can work on this.

Is it ok to just display plain MIME types or should I find a way to translate them into file extensions (guess that would require a bit of work...)?

@emilekm commented on GitHub (Nov 19, 2019): I can work on this. Is it ok to just display plain MIME types or should I find a way to translate them into file extensions (guess that would require a bit of work...)?

GiteaMirror commented

2025-11-02 05:32:31 -06:00

@guillep2k commented on GitHub (Nov 19, 2019):

I can work on this.

Is it ok to just display plain MIME types or should I find a way to translate them into file extensions (guess that would require a bit of work...)?

I'd say mime types are an improvement over nothing at all, but not a lot of people know what they mean (e.g. reporters may not be programmers at all), so file type names (e.g. "Word document") is the ideal. But that certainly means more work. Also, things like */* should be considered. I'd go for a closed list of common file types and "3 others" if applies.

@guillep2k commented on GitHub (Nov 19, 2019): > I can work on this. > > Is it ok to just display plain MIME types or should I find a way to translate them into file extensions (guess that would require a bit of work...)? I'd say mime types are an improvement over nothing at all, but not a lot of people know what they mean (e.g. reporters may not be programmers at all), so file type names (e.g. "Word document") is the ideal. But that certainly means more work. Also, things like `*/*` should be considered. I'd go for a closed list of common file types and "3 others" if applies.

GiteaMirror commented

2025-11-02 05:32:31 -06:00

@emilekm commented on GitHub (Nov 20, 2019):

What do you mean by

[...] and "3 others" if applies.

?

I found a really nice list that I'll use.

@emilekm commented on GitHub (Nov 20, 2019): What do you mean by > [...] and "3 others" if applies. ? I found a really nice [list](https://gist.github.com/jimschubert/94894c938d8f9f64c6863b28c70a22cc) that I'll use.

GiteaMirror commented

2025-11-02 05:32:32 -06:00

@guillep2k commented on GitHub (Nov 20, 2019):

What do you mean by

[...] and "3 others" if applies.

?

I mean that despite all our efforts there may be some types that we won't recognize. For those, some kind of placeholder is useful. For example, for:

text/plain, image/jpeg, image/png, application/x-some-unknown-app

We could display:

.txt, .jpg, .png and 1 other.

My point is that we should avoid using the indeterminate "...and more", which gives the impression that the remaining list is extensive.

Keep in mind that if */* is present in the list of allowed content types, it's futil to mention the rest of the types.

One more thing: for each content-type, several extensions might be valid (e.g. image/jpeg can be .jpg, .jpeg, .jpe, .JPG). I'd list only one of them for each content-type.

@guillep2k commented on GitHub (Nov 20, 2019): > > > What do you mean by > > > [...] and "3 others" if applies. > > ? > I mean that despite all our efforts there may be some types that we won't recognize. For those, some kind of placeholder is useful. For example, for: ``` text/plain, image/jpeg, image/png, application/x-some-unknown-app ``` We could display: ``` .txt, .jpg, .png and 1 other. ``` My point is that we should avoid using the indeterminate "...and more", which gives the impression that the remaining list is extensive. Keep in mind that if `*/*` is present in the list of allowed content types, it's futil to mention the rest of the types. One more thing: for each content-type, several extensions might be valid (e.g. `image/jpeg` can be `.jpg`, `.jpeg`, `.jpe`, `.JPG`). I'd list only one of them for each content-type.

GiteaMirror commented

2025-11-02 05:32:32 -06:00

@guillep2k commented on GitHub (Nov 20, 2019):

I found a really nice list that I'll use.

Yeah, that list looks nice indeed! 😄

@guillep2k commented on GitHub (Nov 20, 2019): > > I found a really nice [list](https://gist.github.com/jimschubert/94894c938d8f9f64c6863b28c70a22cc) that I'll use. Yeah, that list looks nice indeed! 😄

GiteaMirror referenced this issue

2025-11-02 12:28:32 -06:00

[PR #3979] [MERGED] Add cli commands to regen hooks & keys #17178

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#3979