Invalidate Contributors Update

[dealako]

Summary

Invalidate Contributors Update

Background

• As a CLA Manager, when I remove an email domain address from the approval list it should remove all employee acknowledgments that match the email domain address criteria unless the employee is also authorized in another approval list criteria.
• As a CLA Manager, when I remove a GitHub organization from the approval list it should remove all employee acknowledgments that match the GitHub organization criteria unless the employee is also authorized in another approval list criteria.

Expected behavior

Employees who were previously authorized under the email domain address or the GitHub Organization should be invalidate when the CLA manager removes the matching approval criteria.

Screenshots

See video referenced below.

Environment

Please complete the following information:

• Environment:
  • DEV
  • STAGING
  • PROD
• Browser:
  • Chrome/Brave
  • Firefox
  • Edge
  • Lynx
• Version: v1.0.XX

Additional Context

Add any other context about the problem here.

Assumptions

If you are assuming certain facts or scenarios, list them so we have a baseline to understand your request.

• Assumption 1
• Assumption 2

Acceptance Criteria

The "done" criteria when this feature or problem is resolved. Such as:

1. Unit Tests added and running in CI
2. Functional Tests updated to cover feature, if applicable
3. Demonstrate the set of capabilities to the product team while the code is running in the STAGING environment.

References

Meeting video/audio: copy the link below to share this recording with viewers:
https://zoom.us/rec/share/U7eGoOmvKlsN0MbSuumuFDPRA089ESL-InAH_OX18sI7hM4puDeCGkNXfBEt2BP3.LaKwvh4bw6vuD0mW

My Gerrit Video: https://cla-project-logo-prod.s3.amazonaws.com/20210316+Gerrit+Workflow+Video.mov

for the Gerrit discussion, start at around 00:31:38 time

• 00:05:15 Approval list discussion

[dealako]

Email Domain Use Case

As a CLA Manager, when I remove an email domain address from the approval list it should remove all employee acknowledgments that match the email domain address criteria unless the employee is also authorized in another approval list criteria.

Inputs/Provided to us:

• CLA Group ID or Project SFID (if project SFID is provided, then lookup the CLA Group ID)
• Company ID
• Determine the (is this passed in or do we need to load it from the CCLA record?):
  • user's email list (current list - could be changed on this API call, so we need existing plus any that have been added)
  • domain list (that was removed)
  • GitHub username (current list)
  • GitHub organization (don't care for this use-case)

Algorithm:

1. Search for the CCLA signature using CLA Group ID and the Company ID - need the Approval List information
   1. signature project_id = CLA Group ID, signature_reference_type=company, signature_type=ccla => returns CCLA signature
2. Search for ICLA and Employee acknowledgments for the CLA Group
   1. signature project_id = CLA Group ID, signature_reference_type=user, signature_type=cla => returns ICLA and ECLA signature records
3. For each signature in the list (ICLA + ECLA) - could be a lot, do this as a goroutine for each item in the list
   1. Grab the signature_reference_id which is the user's ID from the signature.
   2. Load the user record using the signature_reference_id from the signature table as the user_id in the user's table
   3. Review the user record, determine if they have any email address that matches the email domain
      1. If so, is the user's email in the email list, OR is the user's GitHub username in the GitHub username list?
         1. If so, skip - as this user was added as an individual under a different approval list category/criteria
         2. If not, invalidate the signature by setting approved = False, Add a signature Note, Save the signature, make an event log
      2. If not, we are done

GitHub Organization Use Case

As a CLA Manager, when I remove a GitHub organization from the approval list it should remove all employee acknowledgments that match the GitHub organization criteria unless the employee is also authorized in another approval list criteria.

Inputs/Provided to us:

• CLA Group ID or Project SFID (if project SFID is provided, then lookup the CLA Group ID)
  1. signature project_id = CLA Group ID, signature_reference_type=company, signature_type=ccla => returns CCLA signature
• Company ID
• Determine the (is this passed in or do we need to load it from the CCLA record?):
  • user's email list (current list - could be changed on this API call, so we need existing plus any that have been added)
  • domain list (don't care for this use-case)
  • GitHub username (current list)
  • GitHub organization (that was removed)

Algorithm:

1. Search for the CCLA signature using CLA Group ID and the Company ID - need the Approval List information
2. Search for ICLA and Employee acknowledgments for the CLA Group
   1. signature project_id = CLA Group ID, signature_reference_type=user, signature_type=cla => returns ICLA and ECLA signature records
3. Search the GitHub repositories table, find the list of repositories matching the CLA Group. From the list of repositories, grab the GitHub organization name (may be 1, maybe more than 1???). Find the match from the GitHub Organization approval list removal...
   1. Search the GitHub organizations table for a matching record
      1. Grab the installation ID
      2. Create a new GitHub connection object using the installation ID
      3. Query the GitHub Organization to determine the users which are part of the GitHub Organization => response is a list of GitHub usernames (GitHub API call: client.Organizations.ListMembers())
4. For each signature in the list (ICLA + ECLA) - could be a lot, do this as a goroutine for each item in the list
   1. Grab the signature_reference_id which is the user's ID from the signature.
   2. Load the user record using the signature_reference_id from the signature table as the user_id in the user's table
   3. Review the user record, determine if they have a GitHub username that matches from the list of GitHub Org users
      1. If so, is the user's email in the email list, OR is the user's GitHub username in the GitHub username list?
         1. If so, skip - as this user was added as an individual under a different approval list category/criteria
         2. If not, invalidate the signature by setting approved = False, Add a signature Note, Save the signature, make an event log
      2. If not, we are done

[vinod-kadam]

This is deployed to DEV & Staging through https://github.com/communitybridge/easycla/releases/tag/v2.0.11

[manishv09]

Verified the github org and github username invalidation and it is working fine on Staging environment. Please refer the attached video for reference.

[Uploading... #2792-31032021.mp4]

[manishv09]

Also verified for email address or email domain and found it is not invalidating the ICLA. Please refer the attached video for more information.

https://images.zenhubusercontent.com/194341141/35973fc1-30ef-4cbb-a50c-cecdbdb44ba6/_2792_emailinvalidation_31032021.mp4

[vinod-kadam]

This is deployed to DEV & QA through https://github.com/communitybridge/easycla/releases/tag/v2.0.20

[manishv09]

Verified on Staging environment and found still not working, please refer the attached video for reference:
https://images.zenhubusercontent.com/194341141/58e6b8e1-b523-4620-872d-85b288a36a92/_2792_06042021.mp4

[vinod-kadam]

for information.. latest code is deployed to PROD through https://github.com/communitybridge/easycla/releases/tag/v2.0.23

[manishv09]

Verified on Staging environment and found none invalidation of ICLA is still not working. Please refer the video attached for more information.
https://images.zenhubusercontent.com/194341141/a34914dc-8757-48c4-bd58-763c98d0e78a/_2792_08042021.mp4

[manishv09]

Verified with an existing setup and found it is working fine. Please refer the attached video for reference.

https://images.zenhubusercontent.com/194341141/76f2b87f-8cf5-4f82-ba88-157bffb72a09/_2792_oldsetup_12042021.mp4

[vinod-kadam]

Deployed to PROD on 13-Apr.