You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Zoom doesn't allow updates to happen on disabled users. Given I do delayed delete, it is possible that changes to disabled users could come through. Given how Zoom Phone is granted right now in my system, it is likely that the Zoom account would be disabled days before Zoom Phone is removed. We need to remove Zoom Phone to free up the number, and I am running a delayed delete of 100 days on the main Zoom account. So it likely needs to be enabled, changed, and then disabled again.
And given that I am a part of a University System, I get updates to users that have separated from my institution, but are at others. So I can see a username or name change after the person separates while they are still in delayed delete.
When a user is disabled and a change comes through you would expect the connector to, Enable the user, Make the change,
Disable the User. However, When the user is disabled the zoom Phone settings go away automatically.
If the User settings still contains Zoom Phone Feature, Zoom Phone Number, and Zoom Phone Calling Plans this would also get re-enabled. Perhaps before deactivating the user the Zoom Phone Feature should also be reset to false?
Sorry for the huge delay in response. When a user is disabled, their phone settings stay, but are also disabled. The phone services coming back online long enough for an update and then a disable should be fine. Given how my system is setup, the disable of Zoom in general can fire days before removal of phone settings (Zoom eligible is automatic in Grouper, Zoom Phone are manual groups in Grouper that usually drop after 8 days of not being resolvable in Grouper). Given that delay, it can't actually remove phone and the number stays assigned to the person. Due to business reasons, we have delayed delete of 100 and 200 days from Zoom. So the error state lasts a long time.
The other issue is that other data changes much slower than the automatic disable out of Grouper. We want titles and departments in Zoom to go with the directory. Those values drop out of midPoint later, and would error on not being able to remove.
I think what would work for us is if the Zoom Phone Feature is being removed and the account is disabled in Zoom is to enable it, remove the feature, and then disable again. I think for the other updates we can do with it just ignoring update errors if the account is disabled. That means that midPoint would remain out of sync and try to fix it every time, but I think that would work for us. That's what it is doing right now. It's just emitting 17 errors on reconcile. Luckily I was playing close attention today and found the one error in there that was an actual error I care about.
I need it to also update when the user is disabled too. In particular if Zoom Phone goes away at the same time as access, I need Zoom Phone to go away. So I'll need to update the pull request.
Activity
rfrovarp commentedon Aug 15, 2024
And given that I am a part of a University System, I get updates to users that have separated from my institution, but are at others. So I can see a username or name change after the person separates while they are still in delayed delete.
Stephenglfox commentedon Aug 27, 2024
When a user is disabled and a change comes through you would expect the connector to, Enable the user, Make the change,
Disable the User. However, When the user is disabled the zoom Phone settings go away automatically.
If the User settings still contains Zoom Phone Feature, Zoom Phone Number, and Zoom Phone Calling Plans this would also get re-enabled. Perhaps before deactivating the user the Zoom Phone Feature should also be reset to false?
rfrovarp commentedon Jul 10, 2025
Sorry for the huge delay in response. When a user is disabled, their phone settings stay, but are also disabled. The phone services coming back online long enough for an update and then a disable should be fine. Given how my system is setup, the disable of Zoom in general can fire days before removal of phone settings (Zoom eligible is automatic in Grouper, Zoom Phone are manual groups in Grouper that usually drop after 8 days of not being resolvable in Grouper). Given that delay, it can't actually remove phone and the number stays assigned to the person. Due to business reasons, we have delayed delete of 100 and 200 days from Zoom. So the error state lasts a long time.
The other issue is that other data changes much slower than the automatic disable out of Grouper. We want titles and departments in Zoom to go with the directory. Those values drop out of midPoint later, and would error on not being able to remove.
I think what would work for us is if the Zoom Phone Feature is being removed and the account is disabled in Zoom is to enable it, remove the feature, and then disable again. I think for the other updates we can do with it just ignoring update errors if the account is disabled. That means that midPoint would remain out of sync and try to fix it every time, but I think that would work for us. That's what it is doing right now. It's just emitting 17 errors on reconcile. Luckily I was playing close attention today and found the one error in there that was an actual error I care about.
rfrovarp commentedon Aug 1, 2025
I need it to also update when the user is disabled too. In particular if Zoom Phone goes away at the same time as access, I need Zoom Phone to go away. So I'll need to update the pull request.