View Issue Details

IDProjectCategoryView StatusLast Update
0005637mantisbtfeaturepublic2022-04-27 05:55
Reporterrrjanbiah Assigned To 
Status confirmedResolutionopen 
Summary0005637: Project based email notification setting

There has to be a way to set email notification based on the project. Say for example, if more than one project is present, the developer might want to get alert for the project he is working with.

TagsNo tags attached.
Attached Files


related to 0020323 new Update schema to support user preferences for more email events 
has duplicate 0009083 closedgiallu Manage Configuration, I want to email Managers for a specific project of new bugs, but not Managers of other projects 
has duplicate 0021096 closedatrol support notification user preferences at project level 




2005-05-24 07:26

reporter   ~0010198

In 1.0.0a2, the settings for mail notification are on a per project basis through the Manage Configuration -> Email Notifications page. You can select different settings to notify users of events related to issues.

If you are looking to send an email to all working on a project, this is covered in 0003018 or 0003823.



2005-05-25 02:53

reporter   ~0010211

Last edited: 2005-05-25 02:55

thraxisp: Thanks for the reply. But, unfortunately, this is not what I intended.

What you're saying is like admin level management. But think about the developer.

Consider the situation: Company ABC has lot of developers working on different projects A, B, C, D, etc. Each project might be having around 10-20 developers. All developers want to see other bugs (that is working perfect with current Mantis). But, developers want to get email alert only for the project they're working with/particular project say project D. I've checked My Accounts->Preference, but there is no such per project basis alert setting, AFAIK.



2005-05-27 22:34

reporter   ~0010267

Isn't anyone see this as an issue? For us, it looks like a big hindrance--when handling lot of projects and lot of developers. TIA



2005-05-30 04:33

reporter   ~0010272

Just a 'me too'. We use mantis both as issue tracker for the IT-management and as bugtracker for SW-development. User a might want to be emailed on every status change in his Project, but not for changes in IT.



2005-05-31 02:20

reporter   ~0010281

sgrund: Thanks.

Any comments from developers or others? I'm sure, this is a big issue. Is there any workaround or plugin available for that? TIA



2005-05-31 19:50

reporter   ~0010301

I plan to add this for 1.1.



2005-06-01 02:46

reporter   ~0010305

thraxisp: Thanks. Peace to you.

Eagerly waiting for 1.1:-)



2006-07-25 16:29

reporter   ~0013139

What's the current status on this bug? Is it still on track for the 1.1 release?



2008-04-01 11:33

reporter   ~0017522

Like I have seen on the roadmap this issue is now scheduled for Mantis 2.0.

Is this right?
Is there any release date for Mantis 2.0?

We use Mantis like described by rrjanbiah since several years.
Hence we are growing and the amount of projects and products
managed by Mantis is rising continuously the
"per project email settings" would be extreme useful for us, too.




2014-04-15 05:54

reporter   ~0040100

Is there any update regarding this feature?



2018-04-09 10:18

reporter   ~0059489

I'm developing a plugin to address this issue and have per-project notification settings. If this goes alright, I'll try to have my changes accepted upstream later on.

Anyway, my first idea was to use the NOTIFY_USER_EXCLUDE event, but this doesn't help much. Say that we have 20 projects and the user is
interested in a single project: we'd need to (1) enable all notifications for every user and (2) add an exclude configuration for every project that the user is not interested in, otherwise users will be spammed.

The second try was to use the NOTIFY_USER_INCLUDE event. This is better but won't work if we have global notifications disabled since mantis checks for enabled notifications after firing this event.

Here's what I propose: we do a small change to the email_collect_recipients function in email_api.php so that after fetching user notification preferences ($t_notify = user_pref_get_pref( $t_id, $t_pref_field ); on line 440) an event is fired allowing plugins to overwrite those settings for each user. This event should also carry the bug or project id (or maybe both).

By using these two events (NOTIFY_USER_INCLUDE and the new proposed one) plugins would be able to create all sorts of notification settings (e.g. notify an user if a bug of a specific type and project is assigned to a specific user after being reported by another specific user - probably
not that useful, but you get the idea). In my case, we would be able to have per-project notification settings only for certain users without touching global notifications and thus not affecting users not interested in these settings.

What do you think?



2018-04-09 13:50

reporter   ~0059494

Last edited: 2018-04-09 13:52

I believe this is directly in line with 0023842. The goal there is simply to identify specific, useful locations for new events which can then be hooked in plugins.

Rather than asking what people think, if all you want is a new event, I recommend submitting a PR with that one small change and see if it gets accepted toward closing this ticket. Just make sure:

  • The core provides the info your plugin needs
  • That you document the I/O expected
  • That defined usage of the event doesn't break the core
  • That everything continues to work as normal if no hooks are registered


2018-04-17 11:50

reporter   ~0059578

Thanks for the suggestion, Starbuck.

I've opened a PR implementing my suggestion:



2018-04-22 19:46

manager   ~0059637

I'm missing something here. Why isn't a different access level for developers that are working on a project vs. those that are just contributing (e.g. UPDATER) or viewing the project? This has the following advantages:

  • If a user doesn't work on a project, then they don't show in the assign-to drop down.
  • If a user doesn't work on a proejct, then they don't get notifications.

Can someone clarify why that is not a solution?

I agree that we should also consider features like muting an issue or a project, but it would be good to understand the scenarios and why they can't be achieved by the current design, to make sure they can be achieved in a new design. I would also prefer for this to be handled in the core, rather than a plugin.



2018-04-24 09:07

reporter   ~0059662

So @vboctor, the problem is the following: let's say that a manager has 20 projects but he's interested in receiving notifications for new issues for only three of them. Currently he/she either needs to disable notifications on new issues for every project or enable them for everything.

You have the include and the exclude events that could help us creating a plugin to solve this, but they also require all notifications to be enabled otherwise users added by the include event will be later removed when checking user preferences and the excluded event won't even "see" those users since they were not included in the first place. By enabling all notifications for a user, you then need to manually disable each one you don't need, which will become cumbersome when there are lots of projects and users wanting custom notifications.

I believe that being able to choose to which projects each notification setting applies would be a good addition. What I thought was something like the attached image that uses bootstrap tagsinput. This would probably require that the notifications were moved to another table (not the user preferences table anymore), but should be doable.

What do you think?

mantis-emails-tagsinput.png (12,764 bytes)   
mantis-emails-tagsinput.png (12,764 bytes)   


2018-05-24 19:49

reporter   ~0059933

@vboctor Do you like the idea I proposed or do you think that this is not something contributors should work on?

I'm willing to work on the implementation, but since this is a change to the core it would be better if it was discussed first.
Is there anything preventing this from being discussed at the moment?



2022-04-07 00:13

reporter   ~0066410

Last edited: 2022-04-27 05:55

We are currently making use of the project selector when setting personal preferences for managing columns. Would it make sense to have the same format for personal email preferences? If we separate out email preferences from other system-wide settings (i.e. default project, timezone, font etc) into a new tab that would be responsive to the project selector.