Why is the entire email chain added to the Action Log? #131
Assignees
Labels
question
Further information is requested
Comments
|
They are all really close. What you're looking for is... $includeWholeEmail = $false
$fromKeyword = "From"How the "From" keyword is configured here vs. the original connector is different in that you don't have to include the ":". My original thought behind this was having a more consistency between how one would define keywords without having to remember things like : or [], etc. Just type the word and done. All of this said - it's not a lot of effort, so I'm already thinking this is worth accounting for within the connector via an enhancement request so as to prevent this scenario from happening in the future. Just another way of me saying thanks for the input 😄 |
|
Ah thank you! That explains it. In that case, I think there might be an error in the comments that explain each setting. I can't remember exactly what it states for the It was something similar to: If Shouldn't that be if it's set to false? |
|
You are in fact correct sir. I'll get this updated. |
AdhocAdam
changed the title
AdhocAdam
added a commit
that referenced
this issue
May 30, 2019
Addressing that some WPF controls appear cut off, the title of the Settings window reads "beta 3" and lack of a Private keyword configuration. Updated tooltip verbiage for adding email replies to action log entry per #131 and #132 as well as introduced an icon (e.g. Exchange User Mailbox) for multiple mailboxes.
AdhocAdam
added a commit
that referenced
this issue
Oct 22, 2019
* Settings MP beta 3 Initial commit brings the Settings MP branch to parity with v1.5 functionality and the work performed in the last several months. * incomplete upload It's possible there may have been an incomplete upload from earlier * incomplete upload #2 Missing the actual solution file to load both projects * Beginning conversion Starting to pull configuration from the Settings MP rather than the script itself. * Support for Template Guids/Multi-Mailbox Since the Settings MP now stores templates as their Guid, sections that previously relied on use of Get-SCSMObjectTemplate -DisplayName have been converted to use the -Id parameter instead. However changing template retrieval/variables also has implications on the multi-mailbox feature. As such, the means by which additional mailboxes are retrieved has been altered to obtain those mailbox objects and load them back into the hashtable expected by this particular feature. * alpha 2 MP adjustments Addressing that some WPF controls appear cut off, the title of the Settings window reads "beta 3" and lack of a Private keyword configuration. Updated tooltip verbiage for adding email replies to action log entry per #131 and #132 as well as introduced an icon (e.g. Exchange User Mailbox) for multiple mailboxes. * Updating PS for new properties Per recent management pack changes, the script now retrieves the Private keyword as well as the SCOM defined AD Group * Fixing download/clone annoyance When the branch is downloaded Windows views the file as identical, whereas GitHub does not due to case sensitivity. While this will introduce a break to the blog, it's one that can be easily rectified by updating the respective post. * more fixes. Decimal values in text boxes, deleting multiple mailboxes, and support for ACS priority scoring * Updating AI integration Updating PowerShell to pull ACS and AML based settings from the management pack * More validation Given the importance of keywords to the connector, I really wanted to ensure these incredibly core settings can't be entered incorrectly or accidentally. With the featured regex, keywords can't start or end with a space nor feature any special characters just like the PowerShell configuration. On Cireson portal integration, I opted to simply do a string check and append an "/" if it was missing. Finally, Problem Support Group has been opened up as a drop down. * Didn't upload in previous commit Ensures trailing "/" is placed when using Cireson portal integration. * Beginning PR support group integration Starting to layout the PR support group integration * extending [take] for problem support group Expands the take logic for Problems similiar to Incidents, Service Requests, Changes, and Manual Activities with support for verifying group membership. * Fix for custom events Noticed that custom events wasn't actually pulling from the MP * updating version title Changing version of the seen in the header when opening the UI * Issue with template selection If an Incident, Service Request, Change Request, or Problem Form's appearance were customized via the Authoring Tool. Then Templates created after the import of that form customization MP within the SCSM Console produce Templates that aren't available for selection in the SMLets Exchange Connector. This happens because the act of customizing a Form in the Authoring Tool results in the automatic creation of new Type Projections behind the scenes for that Form based MP. * Aligning with next RC Haven't been keeping the next version in line with the actual release downloads. * Updating AML references Pointing AML properties at the Settings MP. 2 are missing due to a change in v1.6 that will require two additional properties on the Settings MP (work item type prediction). Along with 3 additional properties on the Settings MP for Azure Translation Services. * ACS Translate properties Adding 3 new properties to support Azure Translate integration per v1.6 * ACS Translate data bindings Updating AdminSettingsWizardData (C# code behind to the Settings UI) to reference the new Azure Translate properties on the Management pack (Settings.mpx) * ACS Translate form New form for the Settings UI that surfaces the MP properties for Azure Translate functionality * ACS Translate logo For the Azure Translate form * ACS Translation project inclusion Updating so project builds with new forms and logic * PowerShell update for ACS Properties Updating the PowerShell to pull the new ACS properties that can be defined in the Settings MP * AML Prediction Properties Adding properties per v1.6 changes * AML Data bindings Updating AdminSettingsWizardData (C# code behind to the Settings UI) to reference the new AML properties on the Management pack (Settings.mpx) * AML form update Updating AML form to support two properties for AML prediction reporting per v1.6 * AML update and parsing fixes Round out the AML class extension feature per v1.6. Added error handling for int/dec fields that aren't mandatory. * AML properties and notes Linking PowerShell AML properties to MP. Added notes around each section that convert these guids back to their respective names. Probably will come back to that section to clean up. * AML variable and property conversion Updated the section that converts property GUIDs to their display name to use downstream in New-WorkItem * Updating Versioning and Translation Updating versioning and adding Translation form into WizardStory as a WizardStep * Changing Class Extension logic Previously, the way to retrieve valid class extensions was looking for a specific data type (string, dec, enum) and whose identifier did not contain X. As I'm reviewing this, #130 came to mind and as a result I've changed how the "not like" part of this statement works. Now this is based on the internal name of an MP that the property comes from. This should prove to be far more reliable. * Changing min req Calling out that the upcoming v2 requires 2016 minimum. * Updating placeholder Adding placeholder table for Settings MP description and screenshot. * Updating Settings verbiage Adding some text into the table along with a screenshot from the blog. * updating min version again missed one * grammar and verbiage Removing some redundancy and changing some verbiage * Misleading verbiage The checkbox controls whether or not autodiscover is used, but is phrased backwards. Since this flips the boolean logic for "isenabled" on the autodiscover text box, that's been removed and now it's always available for edit regardless of checkbox setting. Not ideal from a validation standpoint, but is less confusing. * Diff default Work Item Defaulting to the last item in the list. * Incorrect variable Save action wasn't working with the SR comment type/choice. * Ensuring null value This is an example of where the string "(null)" actually introduces a potential issue issue for the PowerShell logic. Will continue to spot check other areas. * SCOM group check If the property is empty, PowerShell will throw an error * Incrementing MPB version vNext Preparing for final v2 release * Error handling for custom actions If for any reason the path can't be loaded, it should provide a custom message in the event the connector is running in SMA or Azure Automation * Adjusting custom paths handling again Moving from a try/catch to a if to see if the file ends in .ps1 (e.g. PowerShell). * Fixing Suggestion Call Function doesn't handle when both values are null. As such, the function runs through it's entire execution only to error out. When returned to the New-WorkItem function, error are thrown to the effect of "Cannot index into a null array." It seems highly likely this isn't unique to v2. Will investigate master branch. * Removing RC2 from title Preparing for v2 final. * updating change notes adding v2 change notes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there, not sure if this is a bug or something I've misunderstood or not set correctly, hence why I've raised it as more of a question than an actual bug.
It revolves around the
$includeWholeEmailand$fromKeywordsettings.I have tried 3 slightly different configurations, but all three yield the same result: the entire email chain (including everything after "From:", not just the reply, is added to the work item action log which I don't want.
Configuration 1:
$includeWholeEmail = $true$fromKeyword = "From"Configuration 2:
$includeWholeEmail = $true$fromKeyword = "From:"Configuration 3:
$includeWholeEmail = $false$fromKeyword = "From:"Which configuration is correct if I only want the reply to be added to the action log, rather than the full email chain?
The text was updated successfully, but these errors were encountered: