[Core] - Reviewing how the locking mechanism logic work - general lock - supann lock.
[Core] - Reviewing how the locking mechanism logic work - general lock - supann lock.
[Core] - Reviewing how the locking mechanism logic work - general lock - supann lock.
Update
First point
The global lock, by clicking on the lock account, is triggering a function in all plugins tabs. Supann only consist of updating account - this will be changed for any supann resource available.
Mail plugin will need to be updated to only listen to password changed or isLocked() which relate to password locking mechanism, only if class supann is not available.
If class supann is available, mail should only listen to the state of its related supann resource and update itself accordingly.
As mail is linked to different mail servers / services - the attribute zimbraAccountStatus must be updated according to the rules above. For it to be triggered and follow the web services update, when the lock is happening - a refresh of the user will happen directly.
Second point
When the supann resource is updated for account, there is call to a core function to lock the password and trigger the locking mechanism via function fillLockingLDAPAttrs in some plugins.
We need an equivalent call to trigger the update of the mail lock mechanism. Can potentially be a generic "refresh" user method in a post_save of supann. Allowing mail to run its methods. (To be tested). This generic refresh triggered could serve different elements in the future.
Note
The related supann (plugin side) update will be linked here. The issue can only fixed in the plugin side (supann).
Second point will be treated in this open PR/MR with its countered part (plugin side) linked within a new issue.
In summary : Locking mechanism review logic will have