starred/CIPP

Fork 0

mirror of https://github.com/KelvinTegelaar/CIPP.git synced 2026-04-25 08:16:01 +03:00

[GH-ISSUE #2963] Editing calendar permissions fails if user added to calendar has a personal Microsoft account #1473

New issue

Closed

opened 2026-03-02 13:44:30 +03:00 by kerem · 7 comments

kerem commented

2026-03-02 13:44:30 +03:00

Owner

Originally created by @kris6673 on GitHub (Oct 30, 2024).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/2963

Originally assigned to: @kris6673 on GitHub.

Description

Disable External calendar sharing
Wait 1 Microsoft minute
Find user with personal MS account with the same UPN
Find a random user to add permissions to
Try to add/edit/remove the user with the personal MS account permissions, from the random users calendar
Observe the success it returns but no edits have been made. The $CalParam.Identity in the return message is blank for some reason.

This happens cause for some reason, the personal account take precedence over the internal user in the tenant. Very odd why this happens.
Changing to use ExternalDirectoryObjectId instead, will make EXO understand that we mean the internal user in the tenant, and not the external personal MS account.

Environment data

Sponsored instance
Frontend: 6.4.1
Backend: 6.5.2
Tried Tenant Cache Clear: true
Tried Token Cache Clear: true

Originally created by @kris6673 on GitHub (Oct 30, 2024). Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/2963 Originally assigned to: @kris6673 on GitHub. ### Description 1. Disable External calendar sharing 2. Wait 1 Microsoft minute 3. Find user with personal MS account with the same UPN 4. Find a random user to add permissions to 5. Try to add/edit/remove the user with the personal MS account permissions, from the random users calendar 6. Observe the success it returns but no edits have been made. The $CalParam.Identity in the return message is blank for some reason. This happens cause for some reason, the personal account take precedence over the internal user in the tenant. Very odd why this happens. Changing to use ExternalDirectoryObjectId instead, will make EXO understand that we mean the internal user in the tenant, and not the external personal MS account. ### Environment data ```PowerShell Sponsored instance Frontend: 6.4.1 Backend: 6.5.2 Tried Tenant Cache Clear: true Tried Token Cache Clear: true ```

kerem

2026-03-02 13:44:30 +03:00

closed this issue
added the
bug

no-activity

unconfirmed-by-user
labels

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 30, 2024):

Thank you for creating a bug. Please make sure your bug is indeed a unique case by checking current and past issues, and reading the complete documentation at https://docs.cipp.app/
If your bug is a known documentation issue, it will be closed without notice by a contributor. To confirm that this is not a bug found in the documentation, please copy and paste the following comment: "I confirm that I have checked the documentation thoroughly and believe this to be an actual bug."

Without confirming, your report will be closed in 24 hours. If you'd like this bug to be assigned to you, please comment "I would like to work on this please!".

@github-actions[bot] commented on GitHub (Oct 30, 2024): Thank you for creating a bug. Please make sure your bug is indeed a unique case by checking current and past issues, and reading the complete documentation at https://docs.cipp.app/ If your bug is a known documentation issue, it will be closed without notice by a contributor. To confirm that this is not a bug found in the documentation, please copy and paste the following comment: "I confirm that I have checked the documentation thoroughly and believe this to be an actual bug." Without confirming, your report will be closed in 24 hours. If you'd like this bug to be assigned to you, please comment "I would like to work on this please!".

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@kris6673 commented on GitHub (Oct 30, 2024):

I confirm that I have checked the documentation thoroughly and believe this to be an actual bug.

@kris6673 commented on GitHub (Oct 30, 2024): I confirm that I have checked the documentation thoroughly and believe this to be an actual bug.

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@kris6673 commented on GitHub (Oct 30, 2024):

I would like to work on this please!

@kris6673 commented on GitHub (Oct 30, 2024): I would like to work on this please!

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 30, 2024):

Great! I assigned you (@kris6673) to the issue. Have fun working on it!

@github-actions[bot] commented on GitHub (Oct 30, 2024): Great! I assigned you (@kris6673) to the issue. Have fun working on it!

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@kris6673 commented on GitHub (Oct 30, 2024):

Gonna fix this after the frontend rewrite, since it requires a change in the frontend

@kris6673 commented on GitHub (Oct 30, 2024): Gonna fix this after the frontend rewrite, since it requires a change in the frontend

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@kris6673 commented on GitHub (Oct 30, 2024):

Hello, I've fixed this issue!

This is what I've done: I have identified the issue with calendar permissions for users with personal Microsoft accounts. The problem occurs because the personal account takes precedence over the internal user in the tenant. To resolve this, I've modified the EditCalendarPermissions.jsx file to use the ExternalDirectoryObjectId instead of the UPN when adding or removing calendar permissions. This change will ensure that Exchange Online understands we are referring to the internal user in the tenant, not the external personal Microsoft account.

I also created pull request: #2964

Caution

Disclaimer: This fix was created by Latta AI and you should never merge before you check the correctness of generated code!

This bug was fixed for free by Latta AI - https://latta.ai/ourmission

Very close, but you need to add ExternalDirectoryObjectId to the returned parameters in Modules\CIPPCore\Public\Entrypoints\Invoke-ListMailboxes.ps1 too, otherwise ExternalDirectoryObjectId will be missing from the table in the frontend

@kris6673 commented on GitHub (Oct 30, 2024): > Hello, I've fixed this issue! > > This is what I've done: I have identified the issue with calendar permissions for users with personal Microsoft accounts. The problem occurs because the personal account takes precedence over the internal user in the tenant. To resolve this, I've modified the `EditCalendarPermissions.jsx` file to use the `ExternalDirectoryObjectId` instead of the UPN when adding or removing calendar permissions. This change will ensure that Exchange Online understands we are referring to the internal user in the tenant, not the external personal Microsoft account. > > I also created pull request: #2964 > > Caution > > Disclaimer: This fix was created by Latta AI and you should never merge before you check the correctness of generated code! > > This bug was fixed for free by Latta AI - https://latta.ai/ourmission Very close, but you need to add ExternalDirectoryObjectId to the returned parameters in Modules\CIPPCore\Public\Entrypoints\Invoke-ListMailboxes.ps1 too, otherwise ExternalDirectoryObjectId will be missing from the table in the frontend

kerem commented

2026-03-02 13:44:31 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Nov 9, 2024):

This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.

@github-actions[bot] commented on GitHub (Nov 9, 2024): This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/CIPP#1473

No description provided.

Rows
Columns