User can't leave quite mode in IE (was: Persistent quiet mode)

[Ryan J Ollos]

I have a use case which may be appropriate for this plugin. Alternatively, it may just require the development of similar plugin. I'd appreciate your thoughts on the following.

We use the ​Jenkins Trac Publisher Plugin to post nightly build notifications to tickets. This is so a dev or tester can know which build a particular defect was fixed in. The problem is, we get a barrage of email notifications every night when the build runs. We want the comments to be added to the tickets, we just don't want to receive email notifications when those comments are added.

I searched around trac-hacks, and this plugin is the closest thing I found to satisfy our need. The problem for our use case is, the quiet mode does not persist across page reloads, let alone sessions.

Do you see a persistent quiet mode setting as a good extension to this plugin? Or should I just use this plugin as an example for developing my own custom EmailDistributor?

[Rob Guttman]

Actually, quiet mode does persist across pages and sessions. It's handled in the backend as a preference.

[Ryan J Ollos]

Okay, that's not what I was seeing, but let me do some additional testing and get back to you shortly.

[Rob Guttman]

Replying to rjollos:

Okay, that's not what I was seeing, but let me do some additional testing and get back to you shortly.

Ok. As an example, when in quiet mode, a git hook ticket association does not generate email notifications.

As you probably know, this plugin requires the Announcer plugin - meaning that it requires that the Announcer plugin is what's managing outbound email traffic.

[Ryan J Ollos]

Replying to robguttman:

Ok. As an example, when in quiet mode, a git hook ticket association does not generate email notifications.

So you have the same use case? You create a git user and put that user into quiet mode permanently?

The behavior I was describing seems to be a defect in IE (specifically tested with IE9 on Win 7 x64).

• Enter quiet mode.
• Refresh page - Enter quiet mode link is displayed again and page background indicates that user is not in quiet mode.
• Enter quite mode again. Try to leave quite mode by pressing the Leave Quite Mode link. The link does not change and the background still indicates that the user in quiet mode.

There is an error message in the console:

HTML1113: Document mode restart from Quirks to IE9 Standards 
1199#comment:7

[Rob Guttman]

Replying to rjollos:

Replying to robguttman:

Ok. As an example, when in quiet mode, a git hook ticket association does not generate email notifications.

So you have the same use case? You create a git user and put that user into quiet mode permanently?

Close but not exactly. When you do a git push as yourself, emails will not get sent out from teh git hook if you are in quiet mode. But your use case should work if you set a given user to be permanently in quiet mode.

The behavior I was describing seems to be a defect in IE (specifically tested with IE9 on Win 7 x64).

• Enter quiet mode.
• Refresh page - Enter quiet mode link is displayed again and page background indicates that user is not in quiet mode.
• Enter quite mode again. Try to leave quite mode by pressing the Leave Quite Mode link. The link does not change and the background still indicates that the user in quiet mode.

There is an error message in the console:

HTML1113: Document mode restart from Quirks to IE9 Standards 
1199#comment:7

Ack. I have not tested this plugin in IE at all. But it's just doing a simple ajax call so not sure why there would be a problem. I'll see if I can do some IE testing when I get a moment later. (I use a Mac.)

[Ryan J Ollos]

Replying to robguttman:

Ack. I have not tested this plugin in IE at all. But it's just doing a simple ajax call so not sure why there would be a problem. I'll see if I can do some IE testing when I get a moment later. (I use a Mac.)

I don't really use IE either, so it's not really a major problem for me. I end up firing up IE when I'm already logged into Trac as different users in Chrome, Firefox and Opera - which is typically the case when testing a plugin like this.

[Ryan J Ollos]

This plugin is really great. I wish I had installed this months ago when you first released it...

On the ticket form, the background is a bit dark, and makes reading ticket comments a more difficult. I don't know if this is possible, but if you could keep the ticket comment box background white, but otherwise change the background of the rest of the page, that would be nice IMO.

[Ryan J Ollos]

Replying to robguttman:

Close but not exactly. When you do a git push as yourself, emails will not get sent out from teh git hook if you are in quiet mode. But your use case should work if you set a given user to be permanently in quiet mode.

I'm testing this out for a while to see how it fits with the daily workflow before enabling it for my whole team. After one day's experience of using this plugin, I've one observation:

We use the post-commit hook to notify users on the team of other user's changes, and this has proven a good means to keep everyone informed. I found though, that I will enter quiet mode and then forget that I've done so, commit some changes and my team won't get notified as they should. So now I have a use case for non-persistent quiet mode, which is kind of funny since my original report here was aiming for the exact opposite feature. But now I can see the value of kicking a user out of quiet mode as soon as they commit their next ticket change, or some similar measure, since the "in quiet mode" message will not be present when committing changes to the repository and it's easy to make a mistake there if you did intend for notifications to be sent.

Alternatively, maybe there is a way to have the Trac post-commit hook ignore any quiet mode setting. I'm not immediately sure how that could be done since the post-commit hook inserts comments as the user that committed the change.

[Ryan J Ollos]

It looks like this might be causes by ​markup errors in the page, and I guess it could therefore be specific to my installation, perhaps causes by another plugin.

[Rob Guttman]

Replying to rjollos:

We use the post-commit hook to notify users on the team of other user's changes, and this has proven a good means to keep everyone informed. I found though, that I will enter quiet mode and then forget that I've done so, commit some changes and my team won't get notified as they should. So now I have a use case for non-persistent quiet mode, which is kind of funny since my original report here was aiming for the exact opposite feature. But now I can see the value of kicking a user out of quiet mode as soon as they commit their next ticket change, or some similar measure, since the "in quiet mode" message will not be present when committing changes to the repository and it's easy to make a mistake there if you did intend for notifications to be sent.

Alternatively, maybe there is a way to have the Trac post-commit hook ignore any quiet mode setting. I'm not immediately sure how that could be done since the post-commit hook inserts comments as the user that committed the change.

A couple of points on this:

• Yeah, getting a workflow to always work exactly as desired is tricky - because it can be very difficult to reliably express the exact rules and enforce the exact control for when you want an email filtered by Quiet Mode or not.
• In addition to a /toggle ajax call, there's also /enter and /leave actions that could be invoked by other scripts (assuming adequate permissions) to try and get the behavior you're after. However, you may need to worry about race conditions.
• If you want certain Trac uses to "remind" users to enter or leave Quiet Mode, you can set up listeners as described here - e.g., one such listener we use is for when you submit a ticket comment while in Quiet Mode it will prompt you to leave Quiet Mode so others can see your comment.

Hope this helps although I now it's tricky. For us, many of us love Quiet Mode and the listeners help us make sure we're correctly in or out of it most of the time - but it's never perfect. In the end, the Quiet Mode feature is worth it for us.

---

As for IE, I have little incentive to dig into that unless it's a real problem for someone. If not, can we close this ticket as wontfix?

[Ryan J Ollos]

Replying to robguttman:

As for IE, I have little incentive to dig into that unless it's a real problem for someone. If not, can we close this ticket as wontfix?

I have hesitated to unleash quiet mode on the rest of my team since there are users on IE, and intend to try to debug the issue, but don't think I'll get to it for a while.

If you close it as wontfix, I can reopen down the road if I ever get a working patch. We should probably add the known issue with IE to the project's wiki page at the very least.

[Rob Guttman]

Replying to rjollos:

The behavior I was describing seems to be a defect in IE (specifically tested with IE9 on Win 7 x64).

• Enter quiet mode.
• Refresh page - Enter quiet mode link is displayed again and page background indicates that user is not in quiet mode.
• Enter quite mode again. Try to leave quite mode by pressing the Leave Quite Mode link. The link does not change and the background still indicates that the user in quiet mode.

There is an error message in the console:

HTML1113: Document mode restart from Quirks to IE9 Standards 
1199#comment:7

Ryan, I just tried but was not able to repro this problem on 64-bit Win7 with IE9. Quiet Mode is working just fine for me. Note that we use SSL in our Trac setup, not sure if that should matter or not?

[Ryan J Ollos]

Replying to robguttman:

Ryan, I just tried but was not able to repro this problem on 64-bit Win7 with IE9. Quiet Mode is working just fine for me. Note that we use SSL in our Trac setup, not sure if that should matter or not?

I tried it again with Win7 x64, IE9, Trac 0.12.3 over HTTPS and still see the behavior described in comment:4. No output in the error console. I wonder if this might be a conflict with another plugin? Looking at the page source, I see MenusPlugin, SectionEditPlugin, DateFieldPlugin, KeywordSuggestPlugin, TracJsGanttPlugin and FootNoteMacro adding javascript to the ticket page.

I have a staging server setup where I could do more in-depth testing to see if the issue is a plugin conflict. I probably won't get to that until next weekend though.