View Issue Details

IDProjectCategoryView StatusLast Update
0005637mantisbtfeaturepublic2018-05-24 19:49
ReporterrrjanbiahAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status confirmedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0005637: Project based email notification setting
Description

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.

Relationships

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 

Activities

thraxisp

thraxisp

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.

rrjanbiah

rrjanbiah

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.

rrjanbiah

rrjanbiah

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

sgrund

sgrund

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.

rrjanbiah

rrjanbiah

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

thraxisp

thraxisp

2005-05-31 19:50

reporter   ~0010301

I plan to add this for 1.1.

rrjanbiah

rrjanbiah

2005-06-01 02:46

reporter   ~0010305

thraxisp: Thanks. Peace to you.

Eagerly waiting for 1.1:-)

radams

radams

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?

mh00

mh00

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.

Thanks

lmc

lmc

2014-04-15 05:54

reporter   ~0040100

Is there any update regarding this feature?

samiraguiar

samiraguiar

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?

Starbuck

Starbuck

2018-04-09 13:50

reporter   ~0059494

Last edited: 2018-04-09 13:52

View 3 revisions

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
samiraguiar

samiraguiar

2018-04-17 11:50

reporter   ~0059578

Thanks for the suggestion, Starbuck.

I've opened a PR implementing my suggestion:
https://github.com/mantisbt/mantisbt/pull/1335

vboctor

vboctor

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.

samiraguiar

samiraguiar

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?



samiraguiar

samiraguiar

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?

Issue History

Date Modified Username Field Change
2005-05-24 06:01 rrjanbiah New Issue
2005-05-24 07:26 thraxisp Note Added: 0010198
2005-05-24 07:26 thraxisp Status new => feedback
2005-05-25 02:53 rrjanbiah Note Added: 0010211
2005-05-25 02:55 rrjanbiah Note Edited: 0010211
2005-05-27 22:34 rrjanbiah Note Added: 0010267
2005-05-30 04:33 sgrund Note Added: 0010272
2005-05-31 02:20 rrjanbiah Note Added: 0010281
2005-05-31 19:50 thraxisp Note Added: 0010301
2005-05-31 19:50 thraxisp Assigned To => thraxisp
2005-06-01 02:46 rrjanbiah Note Added: 0010305
2005-06-17 18:40 thraxisp Status feedback => confirmed
2006-07-25 16:29 radams Note Added: 0013139
2008-04-01 11:33 mh00 Note Added: 0017522
2008-04-24 03:47 giallu Relationship added has duplicate 0009083
2009-05-19 19:45 thraxisp Assigned To thraxisp =>
2014-04-15 05:54 lmc Note Added: 0040100
2016-06-12 19:12 atrol Relationship added has duplicate 0021096
2016-06-12 19:13 atrol Relationship added related to 0020323
2018-04-09 10:18 samiraguiar Note Added: 0059489
2018-04-09 13:50 Starbuck Note Added: 0059494
2018-04-09 13:50 Starbuck Note Edited: 0059494 View Revisions
2018-04-09 13:52 Starbuck Note Edited: 0059494 View Revisions
2018-04-17 11:50 samiraguiar Note Added: 0059578
2018-04-22 19:46 vboctor Note Added: 0059637
2018-04-24 09:07 samiraguiar File Added: mantis-emails-tagsinput.png
2018-04-24 09:07 samiraguiar Note Added: 0059662
2018-05-24 19:49 samiraguiar Note Added: 0059933