[Bug] @user Mention Email Notifications Not Working #7097

New Issue

GiteaMirror · 2025-11-02T07:15:45-06:00

GiteaMirror commented

2025-11-02 07:15:45 -06:00

Originally created by @kdumontnu on GitHub (Mar 31, 2021).

Gitea version (or commit ref): 1.15.0+dev-49-gaee5ef005 (latest master)
Operating system: Windows/Chrome
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes https://try.gitea.io/kdumontnu/test/issues/1
- No

Description

I've tested both on my 1.14 instance and on try.gitea. The @user email notifications don't appear to be working, even though Email Notifications are enabled for users. Nothing relevant in the logs, unfortunately.

Originally created by @kdumontnu on GitHub (Mar 31, 2021). - Gitea version (or commit ref): `1.15.0+dev-49-gaee5ef005` (latest master) - Operating system: Windows/Chrome - Database (use `[x]`): - [X] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [X] Yes https://try.gitea.io/kdumontnu/test/issues/1 - [ ] No ## Description I've tested both on my 1.14 instance and on try.gitea. The @user email notifications don't appear to be working, even though Email Notifications are enabled for users. Nothing relevant in the logs, unfortunately.

GiteaMirror closed this issue

2025-11-02 07:15:45 -06:00

GiteaMirror commented

2025-11-02 07:15:46 -06:00

@zeripath commented on GitHub (May 3, 2021):

So simple testing yesterday on my Dev instance of 1.15 this appears to work...

Have you set:

[service]
ENABLE_NOTIFY_MAIL=true

@zeripath commented on GitHub (May 3, 2021): So simple testing yesterday on my Dev instance of 1.15 this appears to work... Have you set: ```ini [service] ENABLE_NOTIFY_MAIL=true ```

GiteaMirror commented

2025-11-02 07:15:46 -06:00

@kdumontnu commented on GitHub (May 3, 2021):

Have you set:

[service]
ENABLE_NOTIFY_MAIL=true

Ah, no... didn't realize this was set false by default. Will report back if this fixes it.

@kdumontnu commented on GitHub (May 3, 2021): > Have you set: > > ```ini > [service] > ENABLE_NOTIFY_MAIL=true > ``` Ah, no... didn't realize this was set false by default. Will report back if this fixes it.

GiteaMirror commented

2025-11-02 07:15:46 -06:00

@kdumontnu commented on GitHub (May 3, 2021):

This did fix it - looks like it's not a bug. Thanks.

@kdumontnu commented on GitHub (May 3, 2021): This did fix it - looks like it's not a bug. Thanks.

GiteaMirror commented

2025-11-02 07:15:47 -06:00

@pat-s commented on GitHub (May 3, 2021):

For me the error was that env var GITEA__service__ENABLE_NOTIFY_MAIL=true was not set in my docker instance.
By default, notification mails are not enabled and the checkbox must be set during the install page.

But even then, Gitea needs a restart because the mailer is not started when the install wizard has finished (this can be considered a bug probably), so one has to do a docker restart to get all functionality working.

@pat-s commented on GitHub (May 3, 2021): For me the error was that env var `GITEA__service__ENABLE_NOTIFY_MAIL=true` was not set in my docker instance. By default, notification mails are not enabled and the checkbox must be set during the install page. But even then, Gitea needs a restart because the mailer is not started when the install wizard has finished (this can be considered a bug probably), so one has to do a `docker restart` to get all functionality working.

GiteaMirror commented

2025-11-02 07:15:47 -06:00

@kdumontnu commented on GitHub (May 3, 2021):

For me the error was that env var GITEA__service__ENABLE_NOTIFY_MAIL=true was not set in my docker instance.
By default, notification mails are not enabled and the checkbox must be set during the install page.

But even then, Gitea needs a restart because the mailer is not started when the install wizard has finished (this can be considered a bug probably), so one has to do a docker restart to get all functionality working.

Good to know that some install page settings will override initial config settings - not ideal, but it makes sense. I have INSTALL_LOCK=true so didn't run into the problem you mention. Feel free to shoot me a message on discord if you want to discuss how we go about managing docker deployments.

@kdumontnu commented on GitHub (May 3, 2021): > For me the error was that env var `GITEA__service__ENABLE_NOTIFY_MAIL=true` was not set in my docker instance. > By default, notification mails are not enabled and the checkbox must be set during the install page. > > But even then, Gitea needs a restart because the mailer is not started when the install wizard has finished (this can be considered a bug probably), so one has to do a `docker restart` to get all functionality working. Good to know that some install page settings will override initial config settings - not ideal, but it makes sense. I have `INSTALL_LOCK=true` so didn't run into the problem you mention. Feel free to shoot me a message on discord if you want to discuss how we go about managing docker deployments.

GiteaMirror commented

2025-11-02 07:15:47 -06:00

@pat-s commented on GitHub (May 4, 2021):

@zeripath said that the mailer stuff should be started after the install page which might fix the issue. However this would still raise confusion as the install page does not pick up the env var settings and users might be confused.

So it would be ideal if

the install page would honor env vars
the mailer would be started after the install page

I think we should update the docker docs and suggest to set INSTALL_LOCK=true for docker deployments and configure startup related settings like the mailer via env vars.
AFAICS there are some settings which are important to set via env vars during startup while others are fine to set in app.ini only?

@pat-s commented on GitHub (May 4, 2021): @zeripath said that the mailer stuff should be started after the install page which might fix the issue. However this would still raise confusion as the install page does not pick up the env var settings and users might be confused. So it would be ideal if - the install page would honor env vars - the mailer would be started after the install page I think we should update the docker docs and suggest to set `INSTALL_LOCK=true` for docker deployments and configure startup related settings like the mailer via env vars. AFAICS there are some settings which are important to set via env vars during startup while others are fine to set in `app.ini` only?

GiteaMirror commented

2025-11-02 07:15:47 -06:00

@kdumontnu commented on GitHub (May 4, 2021):

So it would be ideal if

the install page would honor env vars

the mailer would be started after the install page

👍

I think we should update the docker docs and suggest to set INSTALL_LOCK=true for docker deployments and configure startup related settings like the mailer via env vars.
AFAICS there are some settings which are important to set via env vars during startup while others are fine to set in app.ini only?

Docs could be improved for certain. All settings should be fine to set directly in app.ini. The problem is that some settings are unique, secret keys. So if you have multiple instances they will be unique for each and also should not be included in source control. For automated deployments it's often best to set these as env vars.

The other option is that you just map the app.ini file to the host. Depends on the amount of repeatability/scaleability you need.

Install_lock=true is really if you want automated deployments. Not necessarily the case for everyone, especially just trying it out or installing only periodically from releases.

@kdumontnu commented on GitHub (May 4, 2021): > So it would be ideal if > > * the install page would honor env vars > * the mailer would be started after the install page 👍 > I think we should update the docker docs and suggest to set `INSTALL_LOCK=true` for docker deployments and configure startup related settings like the mailer via env vars. > AFAICS there are some settings which are important to set via env vars during startup while others are fine to set in `app.ini` only? Docs could be improved for certain. All settings should be fine to set directly in `app.ini`. The problem is that some settings are unique, secret keys. So if you have multiple instances they will be unique for each and also should not be included in source control. For automated deployments it's often best to set these as env vars. The other option is that you just map the app.ini file to the host. Depends on the amount of repeatability/scaleability you need. Install_lock=true is really if you want automated deployments. Not necessarily the case for everyone, especially just trying it out or installing only periodically from releases.

GiteaMirror commented

2025-11-02 07:15:48 -06:00

@zeripath commented on GitHub (May 4, 2021):

Looking again at the mailer - at least on 1.15 this is not being started until after the installer has been run and the settings are set.

The problem might be that line 352 is firing here:

47fd156936/routers/install.go (L345-L353)

@pat-s just confirm you've definitely experienced this issue with a 1.15 install and how you configured the mail system.

@zeripath commented on GitHub (May 4, 2021): Looking again at the mailer - at least on 1.15 this is not being started until after the installer has been run and the settings are set. The problem might be that line 352 is firing here: https://github.com/go-gitea/gitea/blob/47fd1569361a4cb474aa760cefa76c1158c5d944/routers/install.go#L345-L353 @pat-s just confirm you've definitely experienced this issue with a 1.15 install and how you configured the mail system.

GiteaMirror commented

2025-11-02 07:15:48 -06:00

@pat-s commented on GitHub (May 5, 2021):

No, I am on 14.1.

@pat-s commented on GitHub (May 5, 2021): No, I am on 14.1.

GiteaMirror commented

2025-11-02 07:15:48 -06:00

@zeripath commented on GitHub (May 5, 2021):

Would you be able to test to see if you can replicate the problem on main? If it's fixed there then we may be able to figure out what needs to be backported or just leave it and note that it will be fixed in the future

@zeripath commented on GitHub (May 5, 2021): Would you be able to test to see if you can replicate the problem on main? If it's fixed there then we may be able to figure out what needs to be backported or just leave it and note that it will be fixed in the future

GiteaMirror commented

2025-11-02 07:15:49 -06:00

@pat-s commented on GitHub (May 6, 2021):

I've spin up a test instance with 1.15.0+dev-232 and could replicate the issue that when using the install page, the mailer is not started when using docker env vars for mail settings (GITEA__mailer__*) and GITEA__service__ENABLE_NOTIFY_MAIL.

@pat-s commented on GitHub (May 6, 2021): I've spin up a test instance with 1.15.0+dev-232 and could replicate the issue that when using the install page, the mailer is not started when using docker env vars for mail settings (`GITEA__mailer__*`) and `GITEA__service__ENABLE_NOTIFY_MAIL`.

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#7097