AdhocAdam
commented
1 year ago Successfully repro'd. I wrote up the repro steps here just for future reference:
- In the Processing Logic area of the Settings UI, make sure "If Work Item to Update is Closed - Create, Relate, and Copy into a New Work Item" is checked/true.
- Send an email to the connector
- Close the Work Item (Incident or Service Request) however you so choose
- Send an email about the now Closed Work Item e.g. place the [Work Item] in the subject and some text in the body
At this point, a New Related Work Item is created and everything is functioning as designed. In order to replicate this issue and maintain the neccesary Exchange Conversation ID. Go to your Sent Items in Outlook. Find the email you sent above to SCSM, click Reply All so it autopopulates the SCSM inbox address and then
- Send that message
- Send that message a 2nd time, 3rd time, etc.
Eventually the:
- Operations Manager event log will cite an error "Exception Message: Projection"
- SMLets Exchange Connector log will begin refencing two Work Items in events
- Connector gets stuck in a processing loop as it will error out, and repeat the above on the next processing attempt
With the repro steps out of the way, this event actually occurs on Incidents https://github.com/AdhocAdam/smletsexchangeconnector/blob/cb0aeb351bae9089122f75eac3e38cd82ac3e974/smletsExchangeConnector.ps1#L1590-L1591
and Service Requests (as you originally cite) https://github.com/AdhocAdam/smletsexchangeconnector/blob/cb0aeb351bae9089122f75eac3e38cd82ac3e974/smletsExchangeConnector.ps1#L1733-L1734
Now in regards to:
Should an attachment with a specific conversation ID only be able to exist once in a work item perhaps?
That's something I'm not sure we can safely do given another feature that relies on Conversation IDs - Merge Replies. If an Analyst (for whatever reason) somehow deleted the ONLY email attachment that has the Conversation ID, then this feature "breaks" because you'd lose a mechanism to identify the email thread. So that said, I think this might be as simple as introducing a
| Select-Object -First 1in the above searches to ensure we only get a single Work Item which should be acceptable given this is how Confirm-WorkItem works with respect to the Merge Replies feature wherein just a single attachment is selected with a matching Conversation ID.
Now I'll admit, I had to whiteboard this out a bit to make sure I was pathing the email correctly (and I'm pretty sure I did it right). But if I have mispresented something you've stated above or there is a hole in my logic I certainly invite critique.
😃
Describe the bug If an active work item contains 2 attached files (eml) with the same conversation ID, the connector will find the same work item object 2 times, when searching for that conversation ID. This will happen in $relatedWorkItemFromAttachmentSearch on row 1735.
User mails regarding ticket A, which is closed. Ticket B is created with mail as attached file ($CreateNewWorkItemWhenClosed=$true). User mails a second time regarding ticket A. Ticket B is updated with a second attach filed, with the same conversation ID. When user mails a third time from the same conversation, and when $relatedWorkItemFromAttachmentSearch is looking for the conversation, ticket B is returned two times and Update-WorkItem fails from now on when trying to attach files and get affected/assigned user.
Help us reproduce the bug Version of the connector you are using: 5.0 Features/variables you have enabled (i.e. $enableAzureCognitiveServicesForNewWI): $CreateNewWorkItemWhenClosed=$true
Expected behavior The ticket containing the conversation ID should one be returned once.
Location and Environment Where are you running this from? Task Scheduler? SMA? Workflow server?: workflow server What SCSM version are you running? (i.e. 2012R2, 2016, 2016 UR3, 1801, etc.): 2019
Additional context Should an attachment with a specific conversation ID only be able to exist once in a work item perhaps? (replace the current one with the latest if a new mail with the same ID is received)