Old calendar Items get sent to the Blackberry device again when the modification time of the item changes in GroupWise

The customer notices at times that old GroupWise calendar items are being re-delivered to the Blackberry device.

Note:  "Calendar Item" defined as an appointment, task or note :

This is working as designed in Novell GroupWise and currently with BES (Blackberry Enterprise server).  There are many minor changes that can be made to an existing calendar Item that would cause the "Modification Time" of the calendar item to change, such as moving the item to a folder, downloading the item to a GroupWise caching mailbox, assigning or changing a category of the item in the GroupWise client, opening the calendar item and selecting the "Options" tab, and making changes to the available selectable attributes under the General and Security Icons at this "Options" tab location.

Their are likely other reasons and selections in the GroupWise client that can update the modification time of a calendar item, plus the presence of 3rd party applications that may add user or admin defined or other fields into the item records of a GroupWise userxxx.db file via the GroupWise Post Office Agent (POA) and our GroupWise object API's.

1.  When a Calendar Item is posted in a GroupWise Calendar, The data of course is written to GroupWise databases.

2.  If the GroupWise system is connected to BES for data synchronization, the calendar items are written to a database in the BES system and then synchronzied to the Blackberry device.

3.  The Blackberry device normally is set to keep calendar items for a configurable number of days and then the calendar item(s) are deleted from the device.  However when the item is deleted from the device, it is not deleted from the database on the BES system.  If it was deleted from the BES database then that calendar item would be deleted from the GroupWise calendar, obviolusly an undesireable result, since GroupWise can be used to keep track of historical calendar items.

4. When a modification occurs to the calendar item in GroupWise, The BES server can, depending on how it is configured, poll for GroupWise changes or receive a "slap" packet from the GroupWise POA to notify of changes (via SOAP)

Note: Simple example, but not the only possiblity :

5.  Let's say that the calendar item was originally created on January 1, 2010 and represents an effective calendar date of February 1, 2010, also the Blackberry device is set to delete calendar items that are 30 days or older.

6.  Let's say that the day of the calendar item came and went and now it is March 8, 2010 and the user decides to download this and other appointments or notes to his new GroupWise Caching mailbox he setup on his laptop, the act of doing this will change the "modification time" of the calendar items, which the BES server will be notified of and since the data of the calendar item is in the BES system database and not present on the Blackberry device, the BES server will re-deliver it to the device.  This is unfortunately working as designed also on the BES server.

7.  One workaround for users that can use the Object API mode of synchronization with GroupWise is to set a filter on the BES server that can reject the update if it is older than x number of days, like 30 days in this example scenario. However since SOAP is the recomended method for BES to synchronize with GroupWise, this workaround may not be possible, depending on the capabilities of the BES server.  The bottom line is that a code change will need to be considered and implemented by Rim development for the BES server to not re-deliver old calendar items.

8.  This is not a Novell GroupWise issue, it is a Rim (Reserch in Motion) support/development issue.  Hypothetically, If Novell were  to change the GroupWise code to work around this BES server issue, then GroupWise would have a problem with a number of 3rd party applications that interact and synchronize data and events with GroupWise.