Creating a Mailing List for an Issue

There are four types of users for email notification. All these users go through the same validation process as explained in this section.

  1. Interest list users. These are the users qualified to be in the mailing list based on interest list conditions and subscription. Note that if the interest list uses filters with operators such as changed to and changed from then users that are added to the interest list based upon the results of these filters, then the mailing list on the add and edit issue screens will not display these users. This is because these users cannot be evaluated until the issue is updated. Of course, they will receive the notification upon the insertion or update to the issue.
  2. CC Mail users. These are USER IDs or Email addresses entered manually into CC Mailbox
  3. Business Rule users. Business rules may add additional users to the email list before it is processed. These users will be added unconditionally to the email list.
  4. Built-in users. The following users are built-in users and they are automatically qualified to be in the mail list. They are also called standard email recipients. You may suppress this list with the behavior setting named SUPPRESS_STANDARD_EMAIL_LIST by setting it to a value of YES.
Data Dictionary Field Name
OWNER
ASSIGNED_TO
CONTACT
ORIGINATOR
LAST_CHANGE_USER
Previous OWNER
Previous ASSIGNED_TO
Previous CONTACT
Previous ORIGINATOR
Release ASSIGNED_TO
Release OWNER
Module ASSIGNED_TO
UDF list OWNER
Module default OWNER if the behavior setting named EMAIL_MODULE_OWNER_ALWAYS = YES

When an issue is created or updated, ExtraView makes a determination of who is to be notified from the users in the above list, and the rules to process the mail notification are based on the following criteria.

  • Check whether EMAIL_CUSTOMER = YES or NO. This comes from the check box on the add or edit screen. The value is always YES for Custom Email
  • Check whether the behavior setting named SUPPRESS_STANDARD_EMAIL_LIST = YES or NO
  • Check whether each user’s email address and alternative email address is valid – VALID EMAIL ADDRESS = YES or NO. The program checks whether each email address has @ sign within the address and has a “.” at the 3rd or 4th position from the end. Examples of valid addresses are john@extraview.com and john@extraview.com.jp. If the address is not valid, processing does not halt, but the invalid address is dropped from the notification list
  • A check is made to see whether the issue is available for viewing by each user. This is the PRIVACY GROUP TEST which will result in PASS or FAILED. This test is performed by ExtraView. The result is always PASS if the email being generated is an ad hoc email. The basic test results in PASS if the issues’ privacy group is PUBLIC or PRIVATE or the user being tested is in the issue’s privacy group
  • The role of the user being tested is examined. The test results in PASS or FAILED. The result is always PASS if the behavior setting named LIMITED_USER_ROLE is not defined or is blank. The result is PASS if the user’s current role is different from the value of the behavior setting LIMITED_USER_ROLE. The result is FAILED if the user’s role is the same as that defined in LIMITED_USER_ROLE.

    If the result was FAILED, then by definition the user is a GUEST account and the following test is made – if the checkbox EMAIL_CUSTOMER on the add or edit screen is checked, then an email to the GUEST user is generated if one of the following conditions is true:

    • It is an ad-hoc mail that is being sent
    • The behavior setting named ALLOW_GUEST_MAIL is set to YES. Note that this behavior setting is not changeable by the administrator and is only available with a special license key from ExtraView. The reason for this is that access to this key could allow all users to bypass the ExtraView licensing scheme and have unlimited use of ExtraView.
  • A check is made on whether the user is to RECEIVE NOTIFICATION AT PRIMARY ADDRESS = YES or NO. This comes from the user’s personal options. This defines the initial address to which notification is sent
  • A check is made on whether the user is to RECEIVE NOTIFICATION AT ALTERNATE EMAIL ADDRESS = YES or NO. This comes from the user’s personal options. This defines the alternate address to which notification is sent
  • Next, a check is made of the user’s personal option RECEIVE NOTIFICATION ON OWN UPDATES = YES or NO. This checks whether the user who is inserting or updating the issue is to be removed from the notification list
  • Lastly, a check of the behavior setting named EMAIL_MODULE_OWNER_ALWAYS = YES or NO is made. If the check returns YES, then the user ID who is attached to the field MODULE_ID is added to the notification list.

At the end of these checks, ExtraView has a list of the user’s who are to be notified. The process then takes each of these users in turn and creates the outgoing email for the user, based upon their role and all security permissions.