Feat(enrollment): link funding source to group

[angela-tran]

Part of #10

This PR adds a method to Client to link a funding source to a group using their IDs.

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
littlepay/api
client.py
groups.py
Project Total

This report was generated by python-coverage-comment-action

[thekaveman]

Hmm, this is sort of tricky since the behavior crosses different "domains" (funding sources, groups).

But I think ultimately we should be organizing our mixins to align with the structure of the API and where each endpoint is defined there. So I would recommend defining all of this within the GroupsMixin vs. having FundingSourcesMixin mixin the GroupsMixin.

GroupsMixin can still reference the static FundingSourcesMixin.FUNDING_SOURCES to build the required endpoint.

[angela-tran]

@thekaveman Yeah, it is tricky. The API docs have one section for Funding Sources which is all about various methods for getting the ID for a specific funding source, but then under the Products section, that's where we see the methods related to linking between products, groups, and funding sources.

The endpoint for linking funding sources to groups is very similar to the one for linking products to groups.

Whether we have them in GroupsMixin or in their own mixins, do you think they should follow the same pattern?

https://github.com/cal-itp/littlepay/blob/feat/link-funding-source-to-group/littlepay/api/products.py#L43

https://github.com/cal-itp/littlepay/blob/feat/link-funding-source-to-group/littlepay/api/funding_sources.py#L47

[thekaveman]

@angela-tran yeah it is unfortunate that the API docs blend Products and Groups, but it is clear that Funding Sources in the API docs are strictly about GETting funding source by various parameters. I can see us implementing some of those other GET calls in the future in the FundingSourcesMixin for e.g. the manual enrollment feature we've discussed.

I would like to organize our mixins by the top-level API endpoint to the extent possible. Since this operation (linking a funding source to a group) falls under the /concession_groups top-level API, and requires a path parameter to the group_id, that's why I suggest it lives under the GroupsMixin. We will also very soon have to expand to include an optional expiry_date parameter (for e.g. CalFresh) which is a property of the funding source being linked in the group, not a property of the funding source itself.

I think a basic copy/paste of what you have here into the the GroupsMixin would be great.

[angela-tran]

@thekaveman Ok, that all sounds fine. Thanks

[thekaveman]

This is great! Nice work on this full implementation!