Chris:
On my tests, my system behaved differently than yours
in some cases, as I recount later.
I understand more now, which includes the fact that I
still don't fully understand neither the way it
actually functions nor the original intent.
Records on NTE:CFG-NotificationEvents form appear to
play a major role. Not bad, but I can't understand the
overall intent, unless they had a cruel one, not
benign.
NTE:CFG-Notification is the form where system's
default notification settings are stored for different
events and also the same place where user preferences
(set through the update button on profile's
notifications tab) are stored.
I have a custom System Default on this rec, that says
that for Incident assignments, no pages should go out
and email should go out all the time.
With this setting, and no user specific setting, the
moment a group's On Call flag is set:
(1) ALL assignment emails cease. They never go out, no
matter what combination of variables I try, similar
to the ones you experimented with.
(2) Pages go out as defined on On-Call form, for the
specified times. System completely ignore any
preference on user's profile such as "Notification
availability". System also completely ignores group's
business hours. All the system looks at is the "Paging
Times" on the on call form (and the priority there).
To make matters more interesting, now if any user were
to specify their personal preference for email on
their profile, the emails will go out as expected.
So the lesson I learned is that if a group's on call
flag is set, emails no longer go out based on system
default rules, but only based on group member's user
defined rules on NTE:CFG-NotificationEvents, for the
users that have set these rules.
I don't know if there are other variables that make my
ITSM 7 installation behave the way it behaves.
And I also don't know if this is a brilliant design
the subtleties/benefits of which I fail to grasp, or
it's as crappy as it appears to me.
My custom system default records on
NTE:CFG-NotificationEvents look not very different
from out of box ones, so I'm not sure why my system
behaves differently than yours. What does your system
default record say for Incident assignment?
I suspect that some smart group of people schemed to
throw a challenge out there to see if I can figure
this one out before ITSM 8 hits me like a ton of
bricks. Cruel, very cruel.
Or, I imagine a bunch of very brainy people waiting to
see how soon somebody figures out that the intent was
to Insanely Torture System Modifiers 7 days a week.
When I removed the on-call entries from the support
group, normal
notifications resumed.
I tried again with the business hours for the group
and the on-call
hours carefully set to NOT overlap at all (differ by
00.00.01), and with
on-call defined (and the flag set per pg. 180 in the
config guide) then
when I entered an Incident that met the on-call
criteria during regular
business hours, I got a regular notification instead
(the regular
notification was actually NOT set to Yes for Use
Business Hours or Use
Business Holidays - most of our support staff here
WANT email
notification 24x7 - but it also worked just now when
set to Yes). When
I changed the business and on-call hour cutover to 4
PM (17 minutes ago)
and entered a ticket that met the on-call criteria
(Critical), I got
paged via the on-call setting. When I entered a High
ticket which did
not meet the on-call criteria, AND I have my normal
notification set to
24x7 (Use Business Hours = No), I got the normal email
notification of a
ticket assignment to my group.
The time schedules appear to be critical, and setting
normal
notifications to Use Business Hours can result in
tickets which do NOT
meet the on-call criteria (mine is Critical), AND are
after business
hours, generating NO notification whatsoever. Is that
what you are
experiencing?
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the
tools to get online.
http://smallbusiness.yahoo.com/webhosting
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
