-
Notifications
You must be signed in to change notification settings - Fork 378
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: API to list role-holder addresses #7291
Conversation
I think we should use a separate api token named for this view. We may have additional clients of the APIs in the future, and we should be able to make the decision to limit one of the other of these endpoints from those additional clients. |
The functionality looks fine. The list of groups to scrape from should get leadership review (I expect we will add groups and group types to it), but that does not have to happen now. |
I think I'm done now. In addition to straightening out the API token reuse, I realized I'd deviated from the pattern used for the last few API endpoints. I've refactored to do the Group-specific work in May not be perfect, but it's at least consistent. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7291 +/- ##
==========================================
- Coverage 88.98% 88.83% -0.15%
==========================================
Files 291 291
Lines 40717 40881 +164
==========================================
+ Hits 36233 36318 +85
- Misses 4484 4563 +79 ☔ View full report in Codecov by Sentry. |
Adds API endpoint needed to decouple the
makewhitelist
script from the datatracker.The code is refactored compared to the old
list-role-holder-emails
script (final version here), but I confirmed that at least for a recent dev database, the refactored and original code agree.Also: I've reused the
ietf.api.views.email_aliases
API token here because it's what the rest of the API calls used by the postconfirm scripts use. I'm a little uneasy about the now misleading name, but have kept it for operational simplicity. I'd be open to either renaming the token or using a dedicated token for this endpoint.