I think I may be blind.

Does anyone know how to change the global default Autowatch setting in JIRA Software 7.0?

Thanks,

Terry

UPDATE: never mind, found it!

Why don't we just call it 'Default Autowatch' ?

We're going with "Users who create or comment on issues will automatically watch those issues."

'gg' - no.

However the current label for this is far too verbose:
"Users who create or comment on an issue will automatically be watching for future changes to this issue."

Please change that to something more simple.

Do we need a separate issue for gg for autowatch, should we hold up the feature for it, or should we ship without it and not ever ship it? My personal opinion is we can ship without it working with gg because it's not the sort of thing we expect people to change a lot. I don't think we need to ever add it.

Testing observations

Discoverability may be an issue (no gg shortcut for autowatch) - it's under User Preferences which is the right place for it
Websudo is respected
If the user profile for autowatch is "Inherit from global settings" then changing to disabled in user preferences is applied to all future issues created
Changing from enabled to disabled and vice versa does not alter existing issue watch lists.
On upgrade the default user behaviour is "Inherit from Global Settings" if the user has not explicitly changed it
If a user has changed to disabled, it is still disabled on upgrade
New users default to "Inherit from Global Settings"

kudos to Atlassian for noting the critically of this FUG. thanks.

And there's no plan to enable Administrators to completely disable autowatch? By my reading, that's still a (big) requirement for more than a few people who have participated on this issue. The Admin options should be between "off", "autowatch" and "don't autowatch".

We're currently targeting this at 5.2.2. Whether it makes that release or a later one depends on a few factors.

The current plan is to make it so that, after upgrading, people who have explicitly set their preference will retain that preference, but other users will use the default. Administrators will be able to change the default, which will be reflected in the notification behaviour of anybody without an explicit preference. Users will be able to manage what their preference is from the options autowatch, don't autowatch, and default.

Making this turn on for all users by default was a horrible idea!
Spams old and new users alike, more importantly, customers that use our system are quite suddenly getting a pile of extra emails for no good reason.

Hi Atlassian
Which release do you try to develop for? ie. for JIRA 5.1.9, 5.2.1, 5.3 ...

hermann, thanks!

While waiting for your listener, I started playing around with Atlassian SDK and building plugin/listener examples.

With additional help from user-created-manually-event (2nd answer), I manage to create a listener (in Java) that upon receiving a UserCreatedEvent, disable the AutoWatch (& keyboard shortcut as well) as a workaround.

Sorry for the long delay fabian9. Thanks for your interest alvisyky. Find the Listener-Skript I wrote (plus some "documentation") here: http://homepage.uibk.ac.at/~c102180/JRA-28268/
Any feedback is welcome!

hermann, that is a great idea! I would be interested in the listener as well.

hermann I would be interested in that listener script as well.

I've made this into a Fug so I can track it with the bugs without pulling every feature request into that backlog, and so we can use the bug workflow. This does not mean we consider it not to be a feature request.

sdudley you should be able to accomplish most (or all) of this with a Listener (in a plugin or as a groovy-script using the Script-Runner Plugin) that listens to "User Created" events.

I am not at work right now but tomorrow I can post the Listener we are using (to automatically disable autowatch upon user creation and for moving those users to a special group) if you are interested.

I'm happy to provide the patch that we applied, although it's definitely not supported and it's use-at-your-own-risk! It also does slightly more than just remove the autowatch (see below).

You'll first have to download a copy of the JIRA sources from your MAC account, corresponding to the exact JIRA version you have installed. Next, find the directory tree in the source under "jira-project/jira-components/jira-plugins/jira-mail-plugin", and move that jira-mail-plugin directory somewhere else so you can work with it. You also need to install the Atlassian Plugin SDK, if you don't already have it.

Next, apply the patch to the newly-moved directory. Our patch is for JIRA 5.0.7, although it can probably be tweaked to work against other JIRA versions. (For a different JIRA version, in pom.xml, you'll need to modify at least the <version> for the jira-plugins artifact and the <jira.version> in the properties, and perhaps make other version-specific changes to the rest of the patch as well.)

Anyway, the JIRA 5.0.7 patch is here:

http://www.arsenalesystems.com/sites/default/files/jira-5.0.7-mail-plugin.patch

Next, build the jira-mail-plugin project with "atlas-mvn package", then upload the resulting JAR into JIRA...and test carefully.

This patch is part of some other tweaks that do more than just turn off autowatch (and I don't have time to separate them out right now), so please take note of the following:

• as advertised, this patch will automatically disable autowatch for any new users created by the internal mail handler. Note in particular that it won't turn off autowatch for existing users that have already been created. It also won't help if you are using a third-party mail handler.

• we didn't ever want to send notifications to users created by the mail handler, so we commented out the notification feature. If you need it, you can turn this back on in the AbstractMessageHandler class at line ~1223.

• we also didn't want users automatically added to the jira-users group, but rather, we wanted them inserted into a different group (jira-secondary-users). If you don't want that feature, comment out removeGroupsForNewUser() and addGroupsForNewUser() in AbstractMessageHandler on lines 1233/1235.

• the plugin version is set to "6.0.0" in the pom.xml, which is required so that the UPM will install it over the 5.x system plugin in JIRA itself. (If you try to set it to the same version as your existing JIRA version, the UPM will refuse to install it.)

• this is messing with a system plugin, so you are doing so at your own risk. You will need to be careful to keep the mail plugin updated in lockstep with JIRA, since the mail plugin depends on JIRA internal APIs that may change without notice.

sdudley, could you list the steps you took to patch it?

@Brendan: we had the same problem as you on a production system. We ended up having to work around it by patching the JIRA mail handler to explicitly disable autowatch immediately after creating the user. The solution was not particularly elegant (and it requires that we upgrade our patch to the mail handler in step with JIRA), but it's one possible approach that works.

I recently ran into a problem with this as well. Specifically, I've enabled the email handler that creates tickets via email. This creates a user, and forces them to auto-watch the issue. In turn, I can't prevent them from being notified on nearly every change without removing the ability for individuals to effectively watch the issue.

This entire scenario would be solved if I could disable auto-watching by default.

I disagree with the fact that this issue is a "New Feature". It is at least an "Improvement" but rather a "Bug" given that it prevents people to upgrade to JIRA 5.1. Atlassian, please comment and give feedback on this.

I think that the main problem here is that Atlassian decided to change the default system behaviour when they added this feature.

Even assuming that they did not had time to fully implement the future, I do consider an important product management mistake to accept the change of default system behaviour without providing a way to configure jira to match the old system behaviour.

A first fix would be to release a hotfix that changes this. Later, they can release the feature again with the right options.

I reckon that this is a good feature. BUT, it should be turned off by default and allow Users to turn on if they want it to be. OR, allow Administrator to have the ability to default set the feature. We had v5.1.4 and the amount of email notifications are killing the smtp server when we are testing the setup and workflow before rolling to UAT for business users to test. I can't imagine the amount of notifications it will generate for UAT & PROD...

Please take a serious look at this feature. Its really a user-experience killing feature.

+1 as well. We have notification schemes where we want to notify watchers but NOT the reporter of the issue. Having the reporter automatically added to the watchers just ruins the whole thing if we can't disable it. We have jira connected to crowd connected to LDAP where there are thousands users and on which I have no rights access. I can't change their profile...
Looks like JIRA5 introduced a lot of hidden limitations that just break down the administration power, like the 10-chars only limit of jira keys. All these makes me wonder if it's worth upgrading to J5 (we're running J4.3.4 currently) despite all the good new features...

This "feature" to enable autowatch is a no-go for our upgrade from 4.4.5 to JIRA 5.1.x. since our Notification Schemes rely on this to be turned off and have the user by himself set the watcher active if needed. Please fix asap.

This field should also be editable like the "Active" one in the User browser. It's a real pain to disable it for service accounts.

This "feature" (I mean: to turn on notifications by default) is really nonsense.
It is required that it is turned off for all users.
Please also provide a patch for older versions.

Thx
Andreas

I would add to the list that you should be able to configure what the autowatch feature does (e.g. add someone who comments to watchers but not add the reporter to watchers). I am thinking in particular about a team lead who files 500 issues, but does not want to automatically get notified for every single one unless he left a comment in one.

I agree, this is a nice feature but should most definitely be "OFF" by default. Please Atlassian, change it to "OFF" by default and/or add the possibility for administrators to globally change this. Only workaround now is to turn off notifications entirely or have every user to manually change the setting.

I'm desperate to be able to globally turn it of by default. Then each user that want to is free to add it.
/Lars (Saabgroup)

I would really push for Atlassian to add this to the next point release (5.1.4). We help a number of companies in managing their JIRA installs and all of them are unhappy with this change. We have recommended and implemented running script as a temporary fix, but we get a lot of push back. We have many that are simply refusing to upgrade, which we are strongly recommending against due to security reasons.

I would suspect that the fix of having a setting would not take that much effort, and would save many of us a lot of heartache.

Respectfully,

Jeremy Neuharth
Founder | Sycorr

I hope that solves this problem quickly for an atlassian version 5.0 x.
The problem of updates to higher versions is that plugins should also be updated.
E.g. the last update for greenhopper I need rollback to an earlier version because the new features in Greenhopper
were blocking for projects.

I find this change to be particularly problematic because the autowatch feature was introduced in a minor "point" release of JIRA. With the recent 2012-08-28 critical security advisory, we were forced to upgrade an existing 5.0.1 system to 5.0.7, which meant that this "feature" was forced whether we wanted to take it or not.

It would be one thing if we were to upgrade to JIRA 5.1 or 5.2 and have new features like this appear, but it's an entirely different scenario when we need to upgrade a system on very short notice, and then have to deal with this kind of fallout.

(It's great that JIRA 5 now has a stable API, but it kind of sucks that minor point releases are still allowed to break notification schemes...on purpose. Maybe this is better suited to a more philosophical discussion of "should there be new 'features' introduced in point releases?")

If one didn't read the release notes carefully, this might result in embarrassment, inadvertent information disclosure to end users, or worse: many people have notification schemes that specifically omit the reporter from the notification list for certain types of events, and this feature wipes out that distinction.

Just to add my two cents (again)... I am on an hosted instance and will be migrating to OnDemand. Third party plugins or direct DB updates are not an option for our instance of JIRA. We need this to be supported out of the box.

I am still quite surprised this feature was rolled out without any ability to disable this system wide for all users. I would like to second the suggestions by others to classify this as a "Bug" and not a "New Feature". All existing configurations regarding notifications can be administered on a system wide level. As far as I know this is the only one that requires users to go in and edit it themselves. This "feature" (as it is currently classified) should have only been released with the ability to disable it as an administrator.

As other people have also mentioned, I am concerned about my users now getting too many unintended notifications (ie: JIRA spam) which would lead them to ignoring notifications that they should see and respond to.

I too think this is a big problem for sites that need a strict and carefully set up notification scheme (as we do).

My workaround (to disable it globally) was to read the link provided by Mike in the very first comment to this issue: Install the Script Runner Plugin and use the script provided by Jamie on answers.atlassian.com. With a minor change (see my answer: https://answers.atlassian.com/questions/54126/can-jira-s-autowatch-be-disabled/76067).

If you have Script Runner installed you may go to "Plugins" - "Script Runner", paste the script into the "Script" field and check "Groovy" as Script Engine and Run it.

Atlassian – please provide an update on the status of this and escalate priority. There hasn't been an Atlassian update in 2 months.

This has broken JIRA for many admins given the permissions and notifications schemes carefully set up and expectations on information visibility and frequency of updates as a result.

It also causes mail loops if a commenter on an issue has the email address of a mailbox routed to JIRA itself (e.g. internal support engineers responding to external support desk/help desk inquiries from a common mail address like support@ which aliases to jira@).

Please also change this to a critical "bug" – it's critical functionality that was working in JIRA and has been broken by the auto-watch introduction. No reasonable workaround available short of db manipulation.

Terrible feature, especially for administrators who create or move a lot of issues. The worse thing is that you can't bulk unwatch, which at least would have been an acceptable work around. Please turn off!

+1

I completely agree.

I am very surprised that this feature was rolled out with no way to administer this system wide.
I already have notifications configured for the various project roles, groups, assignees, reporters, etc.
Watchers are really if you are interested in an issue and want to ensure you get all notifications.

There have to be a possibility to disable this in the User Preferences. This "feature" is really annoying, when it is enabled by default.

Same for us. It should at least be possible to disable it in the System menu.

Agree. This is a major issue for us as well using JIRA as a help desk solution.

Best regards,
Anders

We (a dutch group of users at the InTraffic company) comply with the previous entry by Carlitos.
The autowatch feature is totally unwanted. We prefer to choose for ourselves to watch or not to watch an issue.
Hopefully this bug will be fixed soon.

This totally sucks!!! I found it the hard way. Is there a SQL script to run against the database and turn it off for all users?

Since updating to the newest version of JIRA this has been an issue for us. We have our notifications highly tuned to what our users want. I understand that many other instances may not, but now I have all my users complaining of JIRA spam (exactly what we don't want to happen as they ignore them).

I have given direction that they can shut it off for their own user, but they are not liking the solution. It is ok if a user wants to turn it on, but for us having them all turned on is not an option our user base is excepting.

Respectfully,

Jeremy Neuharth
Founder | Sycorr

This is a terrible and unfortunate unilateral change. Atlassian should have consulted before changing such a policy. Let's make it an option in the administration as it should have been from the beginning.

We too have problems with this feature. Projects use a notification scheme that makes "autowatch" annoying

+1. I'm sure we're not the only ones using Jira as a help desk solution and this is a big change. Anyone who uses JEMH to parse external emails is probably in the same boat in regards to this change.

We definitely need this issue resolved as quickly as possible. I would have preferred to see this implemented as an "opt-in" feature - i.e. each user must explicitly turn the auto-watch function on if they want it. Having it implemented such that it is on by default and users must individually disable it is quite painful in our environment, especially given that many of our customers use JIRA to communicate with our team and don't want the extra email volume created by auto-watching.

Thought I'd +1 this, in addition to highlighting that I got my "Notable Question" badge for this very question:
https://answers.atlassian.com/questions/54126/can-jira-s-autowatch-be-disabled
(should be worth a couple extra votes, that badge, no?)