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

An overall test is made to determine whether to send email notification in the following steps:

  • The behavior setting named EMAIL_NOTIFICATION must have a value of YES
  • The setting named EMAIL_DIRECTORY must have a valid path into which emails may be written, and the BatchMail task must be running
  • Correct values must have been established for the settings named EMAIL_FROM_USER_ID, EMAIL_FROM_USER_NAME, EMAIL_ADMINISTRATOR_ID and EMAIL_ADMINISTRATOR_USER_NAME
  • If the field named NOTIFICATION_GENERATE_EMAIL is not contained within the add or edit screen layout or the user role lacks permission to the field, then the value of the behavior setting named GENERATE_EMAIL_BOX is used to determine whether to generate the email notification.  This setting must then have a value of CHECKED for notification to be sent.

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.  Note that this setting has a default behavior setting value, but it may be controlled PROJECT by PROJECT on the List Management screen for each Project.
  • 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.