Repository navigation
Post into the most recent of several matching group chats - #22
Merged
Merged
Conversation
When more than one group chat has exactly the sender and the recipients as members, Send-ScriptMessage_MicrosoftGraph posts into the least recent one. The chats are sorted most recent first, but the match loop never stops, so the last match wins. Stop at the first match. With Chat.Read the most recent chat is the one with the latest message; with only Chat.ReadBasic it is the one most recently created, renamed, or given different members, because Graph does not change LastUpdatedDateTime when a message is posted. Correct the comment that said otherwise. Measured against a tenant on 2026-09-30: Graph creates a second group chat with the same members rather than returning the first, and posting leaves LastUpdatedDateTime alone. Chat.ReadBasic cannot expand lastMessagePreview, so that sort is the best it allows, and a delegated sign-in carries every permission already granted to the app, so the Chat.ReadBasic sort applies only when the app has no Chat.Read grant. See Research_Notes/Microsoft-Graph-Behavior.md section 9.
The Chat.ReadBasic sub-bullet of the group chat entry says messages "don't count" and describes the permission grant in terms the reader has to work out. Say plainly which chat each permission picks, and state the case where both permissions are granted directly.
Section 9 says a recipient given by an alias never matches an existing
group chat. A chat member is named by users('<address>'), which takes a
user ID or UPN, so a true alias more likely fails when the chat is
created; the case that never matches is a UPN that differs from the
primary email.
Describe the UPN case, note that matching on userId would avoid it, and
mark the alias case as a likely creation failure.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When the sender already has more than one group chat with exactly the same members,
Send-ScriptMessage -ChatType Groupposts into the least recent one. The chats are sorted most recent first, but the match loop never stops, so the last match wins. The bug is in 1.1.1.This stops at the first match, so the message goes to the most recent chat:
Chat.Read(orChat.ReadWrite): the chat with the latest message.Chat.ReadBasic: the chat most recently created, renamed, or given different members. That sort usesLastUpdatedDateTime, which posting a message doesn't change, andChat.ReadBasiccan't readlastMessagePreview.The change also adds two tests, which fail on the old loop and pass now; a Fixed entry under
[Unreleased]; andResearch_Notes/Microsoft-Graph-Behavior.mdsection 9, with the measurements and what they leave unverified.Live testing, with delegated permissions, sending messages only to three accounts I control:
LastUpdatedDateTime.lastMessagePreviewwith onlyChat.ReadBasicfails with 403.Chat.ReadBasicsort applies only when the app has noChat.Readgrant.Chat.ReadBasicgranted, the message went to the more recently created chat, as intended. TheChat.Readpath was run live only before the change, when it picked the older chat; with the change it's covered by the new test.Release classification
Checklist
develop, ormainfor a hotfixCHANGELOG.mdhas an entry in the right section under[Unreleased](added if missing), or the change is not user-visible.\Tests\Invoke-Tests.ps1passes