.
PhonSoft Technical Library
Subject:Read vs Unread Message Issues
Category:Configuration, MailCall, PhoneServer, Unified MailCall

Read vs Unread Message Issues

This section discusses advanced issues concerning Lotus Notes implementation of "read" vs "unread" messages. These issues do not concern the average user, but are included to help the system administrator resolve any unread message problems. There are several issues and instances which can cause confusion and problems with unread message lists matching when calling from the phone and when viewing the mail file from the desktop. Although there are known documented bugs in Lotus Notes in handling unread marks, in almost all cases unread marks can be made to work completely with PhoneSoft.

The list of unread documents for any database for a specific user is stored by Lotus Notes in three places - the Notes mailbox database itself, the user's desktop file DESKTOP.DSK, and by the Notes client as an unread journal log in CACHE.DSK. Most problems with unread marks stem from the fact that there are multiple (sometimes conflicting) copies of this unread table.

When PhoneSoft querries a mail database for unread messages, the Notes APIs return the list of unread documents from the Notes mail database. PhoneSoft then arranges and presents the unread messages to the user. The number of unread messages when calling from the phone should be the same as the number of unread messages when viewing the mailbox from the Notes client or browser on any PC.

** 1. Canonical Name Problem. This is the most common problem with unread marks. Lotus Notes uses the User's Canonical Name to track unread information for that user. That is the sole purpose of the Canonical name field in the PhoneSoft section of the Domino Name and Address Book (NAB). If this field is not correct for a given user, the unread information (for this incorrect canonical name) when calling from the phone will obviously not match the unread information when accessing the mailbox from the user's desktop (the correct canonical name). If this field is not entered correctly in the NAB, the user will call in and initially hear that he has xxx unread messages, where xxx is the total number of messages in his mail file (or view), and NOT the same as the number of "actual" unread messages he sees from his Notes desktop. To find a users correct Canonical name, do the following. Open the users mail file. Find a document created by that user. Highlight that document from the view. Right click and select "Document Properties". Click on the "Fields" tab. Scroll down to the "From" field. The correct Canonical name is then shown on the bottom of the right side (example: CN=John Doe/O=Your Company). Highlight, copy, and paste this Canonical name into the MailCall NAB Canonical name field. Note - do not copy the quotes.

** 2. Mail File Open Conflict. Note that "read" vs "unread" information can be unreliable if the user's mail file is open on the user's desktop at the same instant the user is also calling in over the telephone to access new messages. This is because Lotus Notes updates the database copy of the unread list only when the mail file is closed from the user's desktop. This is exactly the same Lotus Notes situation as when two users are editing the same document in a Notes database at the same time. When the first user closes the document, the database is updated with his changes. When the second user then closes his document, his document updates the database and the first user's changes are lost.

Therefore, if a user has read several new mail messages from the desktop, and has not yet closed the mail file on the desktop, the information that these messages have been read is not yet written out to the database. In this case if the user also calls in, the application reads the database copy of the unread list, and will still show these messages as "unread", even though they have actually been "read" from the desktop. (Because the Notes desktop application has not yet updated the unread list in the database). This situation is automatically resolved by Notes when the user closes his mail file, but it can cause some confusion when first using the application. This is normally not a problem since the user is usually away from his desk when calling in to hear his messages.

** 3. Access Control List Problem. The Notes ID on the PhoneServer PC must have "Manager" access to a user's mail file in order to read or update the unread marks. This is a Lotus Notes ACL (Access Control List) requirement. If the ID does not have manager access, a corresponding error will be shown in the PhoneServer log whenever the user selects to read his unread messages.

** 4. View Issues. By default, the PhoneSoft application looks for and reads messages from the Notes ($Inbox) folder. If you wish to create a custom view, you can create a view called ($PS Review). If this view exists in a mailbox, it will automatically be used instead of the ($Inbox) folder for all telephone based message review. Note that certain column positions are mandatory when using this view. See the sample database installed with the product (PSMail.NSF) for an example. Since the application uses a specific view ($Inbox) or ($PS Review) for message review, only unread messages in that view will be seen by PhoneSoft. If an unread document is in this database but is NOT in this view, it will NOT be seen by PhoneSoft. This is normally not a problem since incoming (new) mail messages are automatically put into this view by Notes.

** 5. Replica Issues. Users can sometimes get confused if the mail file replica they use when calling in to check their messages is a different replica from their desktop mail file. Although unread marks will replicate between these replicas, a user can sometimes get confused if he marks a message read in one replica, and then immediately calls in or opens the other replica and finds the unread information has not yet replicated over.

** 6. Very Old Lotus Notes Server. Earlier versions of Lotus Notes (before Notes 4.5) only support API access to unread marks in local databases, and not to databases on a Notes server. For unread marks to work on one of these old Notes servers, you must do the following. If the Notes Server containing a user's mail file is earlier than V4.5, you must configure that user in the Name and Address Book (NAB) differently, as described in the PhoneServer Help File. (It must be configured as a mapped local drive). If you do not do this, you will see an error message in the PhoneServer log indicating an unsupported function was attempted when that user tries to access his unread messages from PhoneSoft. Normally (for Notes Server V4.5 and later), the administrator fills in both the mail server name and the mail file name in the NAB for each user. For earlier versions of Notes, the administrator must leave the Notes Server field blank, and must fill in a network mapped path (such as Z:\Notes\Data\Mail) to the user's mail file as if the file were local.

** 7. Notes limitations. Lotus has known and well documented problems in handling unread marks. More details can be obtained from Lotus Development. See Lotus Development Corporation Related Documents:

Technical Paper - Are Unread Marks Fixed in Release 5?
Document #: 169936 (Lotus Notes Knowledge Base)

How Do Unread Marks Work in a Notes/Domino 4.x Environment?
Document #: 160731 (Lotus Notes Knowledge Base)

R5: Two Common Unread Mark Scenarios: New Mail Appears Read & Already Opened Mail Appears Unread
Document #: 179683 (Lotus Notes Knowledge Base)

You can minimize (and often eliminate) the effects of these Notes limitations by doing the following:

- Ensure users always access the same mail file replica as PhoneSoft. If users access a different replica of their mail files from PhoneSoft, or if a user sometimes accesses different replicas, inconsistencies in unread lists can occur.
- If one of the replicas is a local replica (on a client), use the "REPLICATOR_SYNC_UNREAD=-1" setting in the Notes.INI file on that client. This will force unread synchronization during each replication, and minimize the possible occurrance of this problem.
- Access all replicas frequently. If you wait long periods of time between accessing a given replica, older unread entries in the Notes journal file can get overwritten and lost before they are replayed to other replicas.
- Avoid using "Mark all Read" or "Mark all Unread" when using very large mail files (over 1,000 documents) with multiple replicas, since the Notes journal file will not track these unread changes to other replicas.
- Finally, if you must use multiple replicas, you can use the Notes R5 Workspace page to unstack replica icons, select two of the replicas, and select Edit / Unred Marks / Exchange Unread Marks to force replication of the unread tables. This is a manual process, but is more powerful than the "REPLICATOR_SYNC_UNREAD=-1" setting because it allows unread replication between multiple server based replicas.
.