Tag enhancement - Messaging system

nickbe commented 8 years ago

A second role field per tag:

Mail limit: (Set limit role for messages)

A new setting per user: 'Mail message level'

Options:

No messages
Standard Messages (The user only received updates mails for tickets he is assigned to and tickets he has created)
Verbose Messages (The user receives update mail for all tickets in projects he participates.)

satrun77 commented 8 years ago

Notification settings should be part of user account.

nickbe commented 8 years ago

You mean instead of the 'Mail message level' we simply don't inform users if a mail is being set to statuses he has no access to?

satrun77 commented 8 years ago

Notification section under account to select how they want the notification to tickets they have access too. Then users have the control over what to receive.

nickbe commented 8 years ago

But I think we should prevent that they receive notifications for status changes if they don't have access to that specific status.

Well I hate receiving to many notifications as a developer.

I think we should simply think about what information each role really needs/wants.

A user is interested if someone starts working on a ticket he created and when it's resolved and closed - But I definetely don't want him to watch the whole ticket flow though.

A developer is more interested in the flow from when the ticket is avaible for work until it's closed, but as long as statuses are only available to managers he shouldn't get involved.

That's why I thought about the 'message role limit' - We'd need to differ between having access to a status and getting informed about it. A user might have no right to set the status 'Working', but he sure is interested when it's set. But when developer/manager switches status back and forth between 'ready' and 'revise' because the developer makes mistakes - I don't want the user to watch this.

This could be easily done with the 'notification role limit' per tag.

satrun77 commented 8 years ago

Any user should not receive a notification about something they cannot see. If a ticket is under the management flow, and if you have the message role set to developer, the developers are going to receive notifications about something they have not access too. Also, what if the users just does not want to receive any notifications. If the setting is under the tags, then we are forcing messages to users.

This is an example, https://confluence.atlassian.com/bitbucket/files/304578655/349503733/3/1400595238365/mng-notifications.png

nickbe commented 8 years ago

Wow. It certainly is a little bit more complex than I intended, but of course being able to decide about notifications that way is far better. Even though I'd like to be able to let managers and developers do things without anyone being notified :)

nickbe commented 8 years ago

Can we combine it like this?

Restrict certain status changes from notification

Update Tags

Name*         [ Working     ]
Group*        [ Status      ]
Bgcolor*      [ ********    ]
Limit Access  [ Developer |v]
Limit Notify  [ User      |v]

Assign notification status per project in 'my profile'

My Profile

First name*   [ Jon       ]
Last name*    [ Doe       ]
Role:         [ User    |v]
and so on...

Projects I'm watchinh

Project Alpha      [ Minimum notifications  |v]
Master project     [ Standard notifications |v]
Project Gamma      [ All notifications      |v]
My little project  [ No Notifications       |v]

-> whereas notifications levels could be:

*Minimum notifications = Ticket and tag/status changes (including close) in tickets
I'm involved in as creator or assignee.  (Default for Users)

*Standard notifications = Ticket, tag/status, and comment changes (including close) in tickets
I'm involved in as creator, assignee, commentator.  (Default for Developers)

*Extended notifications = Ticket, tag/Status and comment changes (including close) in every
tickets of this project. (Default setting for Managers)

*No notifications = Deactivated for current project

-> The [ limit Notify ] is simply a further notification restriction on a per tag basis.

My Example as seen above: Even if the User cannot set the [ Working ] status, he would be informed when a ticket he created receives the [ Working ] status.

satrun77 commented 8 years ago

I have started on this change. I have the following events to fire a notification. Have I missed something?

On any of these events, a notification process will be queue to send email to specific users depending on the roles setup.

New issue added.
Change status tag.
Change resolution tag.
Update the content of the issue (ie. add quote, change description, etc...)
Assign the issue to a user.
Close the issue.
Add comment
Edit existing comment.
Delete existing comment.
Add note.
Edit existing note.
Delete existing note.

nickbe commented 8 years ago

I guess "Adding attachment" is part of "Edit existing comment".

User has been granted access (new Password has been set)

Otherwiese the list seems rather complete.

One thought that always nags me is: How can we prevent too many messages from being sent when making many changes at once?

Like: I'm in the kanban, dragging around some tickets. I change the status of several tickets multiple times back and forth until I've finished to decide which ticket is finally in which state. Same thing with tickets in the list. Sometimes I open, close and reopen several tickets multiple times, making changes here and there and switching the statuses and maybe resolutions back and forth until I'm satisfied.

Is it possible to have a javascript timer (Jquery setInterval?) which runs the messaging queue?

If you would check a minimum delay between now and the last time a ticket was changed then tinyissue could send messages only after enough time has passed and make sure that I only get the minimum messages needed. Additionally the function could be called when logging out.

satrun77 commented 8 years ago

The notifications here are emails sent to the users.

The flow would be: 1 . User performs an action (ie. change tag status).

The system fires the event "Change status tag".
The system queue an action to send an emails to users about the status change.
Background job to be executed every x minutes that will send all emails that are in the queue.

In the step 4 we can process the queue based on last in first sent. So the last status change is sent out to users, then cancel all other previous queue for the same event "Change status tag" on the same issue.

nickbe commented 8 years ago

Perfect. That sounds genius :)

nickbe commented 8 years ago

Hey Mohamed, nothing new ragarding the design so far here. They've had a busy week I guess. Anything new from you?

nickbe commented 8 years ago

currently I cannot make tinyissue send me mails. This script works for me:

<?php
mail("user@couchticket.de","What a nice Test","We should make more tests","From:  admin@couchticket.de");
?>

So sendmail seems ok.

The mail_queue table gets filled over time, but mails do not seem to get sent. Is there a logfile where I could check when this is supposed to happen?

nickbe commented 8 years ago

Since I'm successfully receiving mails now I think I'm closing the issue here. Should there be any problem I'll open a new ticket.

A really very big thanks for the messaging system :-) Closed.

satrun77 / tinyissue