[Partage-Renater] - getAccount method - Proper account updates

Requirements

It seems an issue might exist making the getAccount method logic not efficient.

An adaptation of the method is therefore required in order to :

• Verify if the account exists on the Partage side and create it with proper attributes if not.
• Verify if the account exists on the Partage side and modify with proper attributes values if yes.

A complete re-design of the logic has been worked on. Details below:

User has no mail tab active

• creation of mailbox
• Verification if Partage has an entry already.
• • IF backend configuration says, LDAP is always right. Update the Partage attributes value with LDAP values.
• • • IF the Partage account is reported as something else than ACTIVE
• • • • If backend configuration report to re-active account if not active, Re-activate account and update values
• • • • Else : Error message, account is [status]
• • ELSE issue an error message "Already exist".

If user as mail tab active

• Verification of account exists on Partage and is active.
• If not active -> Error message saying to reactivate the account.

Careful that no emails ca be changed on Update !

New Features
New mail account status within User, Mail Tab

zimbraAccountStatus
    String(active, closed, locked, lockout, pending, maintenance).

Backend config tab renater partage

• Re-activate account if already exist during mailbox creation.
• Trust LDAP and push LDAP Attributes values to Partage. Overriding.
• Removal of tab Mail within User: Delete / Lock.

Descriptive title for this enhancement

[Partage-Renater] - getAccount method - Proper account updates

Actual behavior

It is has been reported that the update on Partage side is not performed properly.

Expected behavior

Proper updates taking the information from the LDAP source as truthful, therefore updating Partage properly.

Step by step description of new behaviour

The getAccount method will update or create the account properly.

Benefits

A better replication of the LDAP information to harmonize the data.

Possible Drawbacks

LDAP is considered the one having the latest and proper information, therefore pushing its data. If Partage contains different attributes values than LDAP they will be updated.

Applicable Issues

None.

changed milestone to %FusionDirectory 1.4

added Added PJ1808-0220 labels

assigned to @tdockx

added 5m of time spent

created branch 6196-partage-renater-getaccount-method-proper-account-updates to address this issue

A quick fix rendering the verification of existing account has been suppressed from the update method.
This has a consequence that values within LDAP are being pushed towards Partage.

The fix is deployed in the DEV environment of Renater.

added 1h of time spent

added plugin-renater-partage label

changed the description

mentioned in issue #6197 (closed)

added 20m of time spent

changed the description

added 5h of time spent

Note : A backend configuration for Partage has been developped regrouping important options related to the workflow of FD -> Partage.

An adaptation of the token access must be required due to a 5m max per token.
As well as a max of 100 tokens sent by domain.
Therefore we have to store the tokens as well as the number of tokens received. A time stamp is required as well.

added 1d of time spent

added 4h of time spent

mentioned in commit 038debb7