View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005637 | mantisbt | feature | public | 2005-05-24 06:01 | 2022-04-27 05:55 |
Reporter | rrjanbiah | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | confirmed | Resolution | open | ||
Summary | 0005637: 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. | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
related to | 0020323 | new | Update schema to support user preferences for more email events | |
has duplicate | 0009083 | closed | giallu | Manage Configuration, I want to email Managers for a specific project of new bugs, but not Managers of other projects |
has duplicate | 0021096 | closed | atrol | support notification user preferences at project level |
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. |
|
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. |
|
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 |
|
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. |
|
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 |
|
I plan to add this for 1.1. |
|
thraxisp: Thanks. Peace to you. Eagerly waiting for 1.1:-) |
|
What's the current status on this bug? Is it still on track for the 1.1 release? |
|
Like I have seen on the roadmap this issue is now scheduled for Mantis 2.0. Is this right? We use Mantis like described by rrjanbiah since several years. Thanks |
|
Is there any update regarding this feature? |
|
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 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 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 What do you think? |
|
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:
|
|
Thanks for the suggestion, Starbuck. I've opened a PR implementing my suggestion: |
|
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:
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. |
|
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? |
|
@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. |
|
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. |
|