Jump to content

Emails used to raise or update requests are not preserved


Martyn Houghton

Recommended Posts

Related to our post below about deleting processed emails from our mailbox below in order to speed up mailbox operations, we have discovered that unlike Support Works where the emails related to a request being logged or  updates from email get stored as attachments to the request itself (CFA attachment store I seem to remember) in Hornbill it is just a link to the original email in the mailbox store.

Therefore when you clear down your deleted items (default) or your own specified folder, where the emails are put after being processed by Raise Request or Apply to Request, you will lose access from within the request timeline entry to the 'View Email' option. The 'View Email' option is still displayed on the timeline entry but you will get the Hornbill error below:-

emailgone.JPG

So if you want retain access to view the source email from within the timeline on a request you need to keep the emails in the mailbox itself, else  This caught us out a bit as we have deleted a large volume of historic emails have which we have processed via Raise Request and Apply to Request, which we cleared down as performance within the mailbox itself was degrading.

Cheers

Martyn

Link to comment
Share on other sites

Hi Martyn,

Sorry for the delay in responding, we have made improvements to the performance of the mailboxes which will hopefully negate the need to hard delete emails for performance reasons in the future.  And we are currently investigating the possibility of introducing a soft delete in cases where the email might be referenced somewhere else in the system.

Will update when we have progress on this.

Thanks

Trevor

Link to comment
Share on other sites

  • 2 weeks later...

@trevorharris

The recent update which added indexes on the mailboxes as helped quite a bit. Our main issue with the mailbox is the refresh/syncronisation between multiple users in the mailbox, which I think was logged as  IN00141912 originally.

We have multiple members of the 1st Tier monitoring the inbox due to the volume of incoming emials.  They will move a message into there specific folder in order to process it, but this does not trigger an update on the other users screens so they still see the email in the inbox. They then pick this up belieinvg it has not been picked up by a colleague and move it into there folder. As the move process does not check the message location, the first user   moves it to their folder and strats the progressive capture proces to log/update the request. In the meantime the 2nd user has move the email into their folder which in practice is not moving it from the inbox but from the first user folder. 

Out users are constantly having to click on F5 to manually refresh the mailbox to check if mail has been moved/picked up.

It would be good if the move process rather than just using the unique id also checked the current folder locaton, so it would fail when the message has already been moved and of course if changes in the inbox by one users triggers all sessions with the mailbox open to refresh automatically. This would minimise duplicate request/updates from emails being logged and remove the need to constantly manually refresh the mailbox all the time.

Cheers

Martyn

Link to comment
Share on other sites

Hi @Martyn Houghton,

You should now be able to see the change in LIVE. We are working on more improvements, especially regarding the performance of events and adding more events like when an email is marked as read/unread. We will be pushing improvements in both client and server gradually, so it will get much better.

Thank you,

Daniel

Link to comment
Share on other sites

Hi @Martyn Houghton,

The new version does not use the experimental flag anymore as it has now a flag per user you can turn ON and OFF from the UI of the email view.

Several issues were addressed and we will continue to improve this.

You can see more info in the forum post 

Please let me know if you find any issues.

Thanks,

Daniel.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...