Fix for Email containing the reactivate keyword won't be added as action log when incident is neither resolved, nor closed

[SimonZein]

Let's say we have:

1. an incident that already exists whose Status is Active
2. send an email, which by accident contains the [reactivate] keyword,
3. The mail and even screenshots, are attached to the incident, but no action log is created
4. The DEFAULT case will not trigger, as both reactivate cases are a match but do nothing because the incident status lets both if-else statements return $false.

Therefore an additional "[$reactivateKeyword]".... is needed in all 3 switch-case statements of the Update-WorkItem (when the WorkItem is an IR).

Maybe this behaviour, as it is now, is desired and it shall not be added as action log. If that's the case, please just ignore this pull request :)

[AdhocAdam]

[AdhocAdam]

Had to do some investigation/looking at some original notes for this one 😃

• In the original exchange connector, if a comment contains a keyword that cannot be used because the associated Action can only be performed once, for example [acknowledge].
  • The comment is left
  • The Action is not taken
  • There isn't any indication that the action DIDNT work
• In the SMLets Exchange Connector, the comment isn't left because I originally thought that the likelihood of someone leaving a comment for an Action that was already performed (or could not be performed) was low/non-existent since several key actions are usually HTML links that people craft via Notification Templates, and I thought that visually it could mean the Action Log became misleading to onlookers. Because if someone started examining each Action Log entry, they might see [acknowledged] twice and come to the false conclusion that someone "moved" the acknowledged time. In your case, there would be two entries for [reactivated], although depending on how it was handled one would have the associated Action Log visual and one would not. In any case with the SMLets Exchange Connector:
  • The comment is not left
  • The action is not taken
  • There isn't any indication that the action DIDNT work

This is all a long way of saying that this lines up with your observation. You can't Reactivate an Active Incident, so the connector processes 2 of 3 changes to the Work Item in that the email is added, the attachments are added, but the commentary is not added. Now, could this be slightly improved? Probably. There is always room for improvement. The 200+ commits to the project and contributors such as yourself have proven that 😄But what I hope you can see is that SMExco just has a fundamentally different approach in this regard. But it also means your pull request actually extends itself into a few other keywords that I also believe open the door to further refinement.

So to play devil's advocate, in hopes of sparking further discussion, and seeing if there is perhaps a middle ground because the nature of your pull request would change something very fundamental about the connector. The question in my opinion becomes what is the ideal experience that offers the least amount of confusion to someone who does not understand ANY of this nuance.

• The comment isn't left = the connector is broken? but the rules of SCSM were obeyed
• The comment is left, the action doesn't happen = the connector is broken? SCSM is broken? something is broken? but it obeyed the rules of SCSM
• This becomes a configurable option that everyone using SMExco can decide for themselves and thus, explain to their respective staff

[SimonZein]

Hey Adam, fully understand what you mean 😉 As for the [reactivate]keyword in the 3rd path (when the Incident is neither resolved nor closed), I have the -Action parameter set to Analyst/User Comment, so there is no visual indication for the action being performed a second time. But as far as I know our end users, they wouldn't even recognize it anyway .🙄 And our users is the reason I implemented it the way I have it now, as I receive questions like "Why is this comment not added?" and not "Why does the reactivate is present twice here"... 😅 I could write a whole paragraph about these complaints or complaints , that this is tooooo complicated and we have to change that because of our poor end users 🙈 But here we are at the point we have been spoken about so often and which makes the connector so excellent - I can just modify it to my/our needs. And I am not in any way mad if one of my pull requests does not find it's way to the base connector. These are just ideas and I fully understand that something that works for us, won't work for others - or even worse, confuses them and makes them stick to the OOTB connector 😖