[GH Request] Automate adding entity CLA contributors to the `openedx-triage` team

[brian-smith-tcril]

Firm Name

Axim

Urgency

Low (2 weeks)

Problem/Request

When someone is covered by an entity CLA they should have triage access.

Reasoning

Adding someone to the openedx-triage team is a standard part of the onboarding process when adding someone to the entity CLA Database. This should be the case for all entity CLAs.

Solutions Ideas

One potential solution for this wolud be to have a github workflow based on the change to https://github.com/openedx/openedx-webhooks-data/blob/main/salesforce-export.csv

When changes merge to main, the workflow could ensure that anyone with an entity CLA has triage access and remove triage access from anyone not on the list (we should check who would get removed in this case, before we decided we want to go this way moving forward.)

[github-actions]

Thank you for your report! @openedx/axim-oncall will triage within a business day. Simple requests usually take 2-3 business days to resolve; more complex requests could take longer.

[e0d]

Notes:

1. The existing report is a csv that is produced daily and mailed to Zapier to trigger a workflow. That report contains a field that indicates whether the s is covered by an entity CLA. This fact should be sufficient to add them to the triage group and covered entities are trusted enough to run tests automatically, one of the main benefits of membership in the triage group.
2. Adding someone to the triage group may require a bit more logic than simply adding them to a group as they may need to be invited to the org and accept the invitation. My memory is that the API will automatically handle sending the invitation
3. Doing this work in the existing Zap wouldn’t be perfectly elegant:
   a. You could open the PR, review the diff in code and programmatically add and remove folks based on added and removed lines.
   b. You could remove everyone and add everyone in the current file back and hope you don’t fail part way through :(
   c. You could do this bit elsewhere and make the process more complex

I started down the 3.c. route attempting to trigger a new Zap based on changes to the data in Salesforce. This could eventually be expanded to make CLA updates “real time.
The issue here is that Salesforce check boxes behave sub-optimally and only fire triggers when they are checked and not when they are unchecked.

The fix for this would be to change the structure that we are using to store that field to a radio, drop down or something else. It would also be possible to utilize a hidden field with an integer based on a query of the count of CLAs. Something like this is being done for the CSV report. I think changing the data field is probably a better long term solution.

We can coordinate with our SF support team to flesh out the recommendation and migrate the data.

Given that SF can be fiddly in unexpected ways, I think experimenting with a test field of the target type before investing in the migration is the correct approach.

The experimental Zap is here:

https://zapier.com/editor/287697466/published

Email exchange related to the underlying problem

This is triggering a memory. I think a prior admin created a field that is updated when this checkbox is checked or unchecked. This field would suit my purpose. I can see the analog that is used for the individual CLA from Zapier, but not the field for the entity CLA. That field is Number of Active Ind. CLA Contracts.

You can see the entity version in this report https://tcril.lightning.force.com/lightning/r/Report/00O5f000006IoO1EAK/view?queryScope=userFolders

Seeing the 1/0 value would let me do what I need to do.

Note from SF Support

Looks like you've got 3 flows using that field but they're all super simple. Because you're actively using them in code, though, SF won't let you change the field type. The process would be:

(1) Create a new field with the picklist options
(2) Update the 3 flows to use the picklist options instead of the checkbox
(3) Delete all prior versions of the flows that reference the checkbox field
(4) Delete the checkbox field

It would take less than an hour to do. Since step 1 is to create the new field, you could safely create the new field, test it with your zap to make sure it works as you need it to by manually changing the data on some test records, and only after you confirm the zap works would we do the rest of the SF side work. So it's pretty low risk to try it.