Feature Request: Ability to set/change reporting user for an issue #2088

New Issue

2025-11-02T04:23:49-06:00

GiteaMirror commented

2025-11-02 04:23:49 -06:00

Originally created by @bkraul on GitHub (Jul 23, 2018).

Gitea version (or commit ref): ca8c7bb
Git version:
Operating system: Linux (docker)
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

We are currently using gitea in our internal development department at at my organization. The software works amazingly and we are enthusiastic about using it to its full potential. One of the situations we encounter is that our users are not really into the habit of logging into the gitea system and reporting issues, like normal github users would.

This presents a shortcoming to us, because we end up entering the issues as ourselves and entering extra information to show who the user it was that reported it (AD setup). It would be tremendously helpful to both provide a way to set the reporting user on issue adding, and to be able to change it when editing the issue. Same thing would go for comments. This would allow us to properly document the issues. Obviously this would need to only be available to users with proper permissions.

Is this feasible?

Originally created by @bkraul on GitHub (Jul 23, 2018).  - Gitea version (or commit ref): ca8c7bb - Git version: - Operating system: Linux (docker) - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description We are currently using gitea in our internal development department at at my organization. The software works amazingly and we are enthusiastic about using it to its full potential. One of the situations we encounter is that our users are not really into the habit of logging into the gitea system and reporting issues, like normal github users would. This presents a shortcoming to us, because we end up entering the issues as ourselves and entering extra information to show who the user it was that reported it (AD setup). It would be tremendously helpful to both provide a way to set the reporting user on issue adding, and to be able to change it when editing the issue. Same thing would go for comments. This would allow us to properly document the issues. Obviously this would need to only be available to users with proper permissions. Is this feasible? ![image](https://user-images.githubusercontent.com/14616851/43093947-3a20c608-8e77-11e8-908c-32ea6dc563ca.png)

GiteaMirror added the type/proposal label 2025-11-02 04:23:49 -06:00

GiteaMirror closed this issue

2025-11-02 04:23:49 -06:00

GiteaMirror commented

2025-11-02 04:23:50 -06:00

@lafriks commented on GitHub (Jul 23, 2018):

I myself are usually try to instruct my users instead of doing something on their behalf so I don't see myself implementing this but if anyone sends a PR for this with special right level and option to enable that (by default disabled) in app.ini I'm not against it

@lafriks commented on GitHub (Jul 23, 2018): I myself are usually try to instruct my users instead of doing something on their behalf so I don't see myself implementing this but if anyone sends a PR for this with special right level and option to enable that (by default disabled) in app.ini I'm not against it

GiteaMirror commented

2025-11-02 04:23:50 -06:00

@bkraul commented on GitHub (Jul 23, 2018):

@lafriks I agree with you there, in principle. However, in the real world is a little bit more complex. While we as developers try to structure an efficient way of error reporting, etc, the users' mindset, especially in a business-oriented environment revolves around "I will just call or email the developer, he'll fix my problem", and care nothing about proper documentation, which more often than not, it has served a great deal in resolution. But yes, a disabled by default functionality would work just fine. This to me is similar to the impersonation feature request I did a while back. Sure, proceduraly is not needed, but if there, it can be of great advantage.

I would PR this in a heartbeat if I was adept at golang.

@bkraul commented on GitHub (Jul 23, 2018): @lafriks I agree with you there, in principle. However, in the real world is a little bit more complex. While we as developers try to structure an efficient way of error reporting, etc, the users' mindset, especially in a business-oriented environment revolves around "I will just call or email the developer, he'll fix my problem", and care nothing about proper documentation, which more often than not, it has served a great deal in resolution. But yes, a disabled by default functionality would work just fine. This to me is similar to the impersonation feature request I did a while back. Sure, proceduraly is not needed, but if there, it can be of great advantage. I would PR this in a heartbeat if I was adept at golang.

GiteaMirror commented

2025-11-02 04:23:50 -06:00