Only allow take keyword to assign if sender belongs to support group

[TomH-OpsDev]

• Only allow [take] if the sender is a member of the current support group
• Send an email to let them know it failed?

https://github.com/AdhocAdam/smletsExchangeConnector/edit/v1.4b-TH/smletsExchangeConnector.ps1#L759

[AdhocAdam]

To add to this - several groups leverage this feature as a means to "Submit on Behalf of" through the connector. It obviously doesn't work that flawlessly because the Sender becomes the Affected User but it visually signals to other analysts that the Work Item doesn't have to get reviewed/picked up by them.

I wonder if there is a way we could address a few things here:

• Only allow assignment if the sender is in the current group
• Enable the ability to submit on behalf of (in an attempt to address a "walking the floor" scenario)
• Allow the ability to peform an Assign Group by Analyst function (this however defeats your original intention)

[TomH-OpsDev]

Actually, I would not say that assign group by analyst defeats my intention. I only want to avoid seeing tickets where the assignee isn't part of the support group. As long as they match, I am less concerned with how we get there, so this could be very useful. However, we would need to handle for situations when someone belongs to more than one support group.

I think I see Submit on Behalf as a separate, new feature, but I like it. Plenty of use cases for it.

[TomH-OpsDev]

Updated: https://github.com/AdhocAdam/smletsExchangeConnector/commit/3e8e7237ad67ec02aae3fd42e37cda1e9dc70f96

Updated this to only honor the request if the sender belongs to the current support group. This includes a new function Get-TierMembership. This function and the IF I wrapped around the [take] command could probably use some more error-checking. Refactoring seems likely, too. This is just to get something started.

[AdhocAdam]

Agreed - the more I look at the ELSE, the more I think this needs to address "Assign Group by Analyst" style functionality. This would prevent us from unfairly penalizing analysts who then in turn must go back to the Console but puts us right back into the position of needing a "Primary Group" style relationship somewhere (i.e. extending the User class with a new relationship)

Second the "on behalf of" as a seperate request - #31

[TomH-OpsDev]

I made the membership check optional in https://github.com/AdhocAdam/smletsExchangeConnector/commit/a362d2e55b1ade259e5cbc39ffbd1c1b2048ab49. It occurs to me that I am depending on Cireson management packs to determine membership, and some users may just not care to enforce this in their process. It will definitely be turned on in my environment, though!

Primary Group relationship/enum intrigues me. Something like that would solve other, unrelated challenges for me. However, that would mean that we now require installation of a management pack for this feature to work. That might be OK, but I want to pause and think about the implications.