The one reason I am leery of relying solely on autowatch (and dropping
participants) is that I am pretty sure that autowatch is not
retro-active. Meaning if you have commented on a issue and have been
receiving continuing notifications there is a danger you will no longer
get notifications. Unless you are also a watcher.
On 03/25/2013 07:28 AM, Steve Ebersole wrote:
The field collects "participants" (creator, assignee,
There is then a rule in the notification scheme which says that all
participants should get notified.
Autowatch is a little different than. Autowatch says to add a person
to the issue's watcher list when they comment on an issue. From there,
they are treated just as if they had manually clicked on watch
themselves in the UI. Users can choose to enable/disable autowatch as
part of their profile (enabled by default). All in all its a better
way to do what we used participants for, imo.
I am trying to figure out the "testcase reminder" field...
On Mon 25 Mar 2013 06:41:52 AM CDT, Hardy Ferentschik wrote:
> On 24 Jan 2013, at 8:25 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
>> I am looking into the problem of hibernate-issues no longer getting
>> notifications. One possible reason is the use of the custom
>> "Participants" field in our notification scheme. I am wondering if we
>> ought to remove that rule from the notification scheme. Atlassian have
>> added an "autowatch" field that kind of does the same thing.
> What does this custom field do exactly?
> I assume the autowatch setting is unrelated to getting initial
> notifications for created issues.
> This is just about getting further notifications once you edit an
> issue or explicitly click the
> watch link, right? If this is the case autowatch works for me.
> On a different note, we have this "Bug Testcase Reminder" field which
> used to render
> some HTML. However, that is broken now and the actual html is
> displayed. How can we
> change that? Either enable HTML rendering on the field again or use
> plain text.