For accounts that share contribution room (e.g. RegisteredAccounts), TransactionStrategy needs to avoid overcontributing by ensuring that it limits contributions to an account if another account in the group is also receiving contributions.
If we were doing this directly in the logic of each strategy, it would likely need to be done differently in different strategies:
In the Ordered strategy, for each account subtract the sum of transactions to its contribution_group members from its max_inflow attribute when determining a proposed inflow.
In the Weighted strategy, determine the sum of transactions planned to be added to those groups in the usual way, then reduce those transactions as necessary (e.g. proportionally to weights) if the group's max is exceeded and recurse onto the remaining accounts with the excess.
Rather than do it that way, which is likely to make subclassing harder, add handling code at the __call__ level by adding contribution_group-aware logic to _recurse_min and/or _recurse_max.
For accounts that share contribution room (e.g.
RegisteredAccounts),TransactionStrategyneeds to avoid overcontributing by ensuring that it limits contributions to an account if another account in the group is also receiving contributions.If we were doing this directly in the logic of each strategy, it would likely need to be done differently in different strategies:
Orderedstrategy, for each account subtract the sum of transactions to itscontribution_groupmembers from itsmax_inflowattribute when determining a proposed inflow.Weightedstrategy, determine the sum of transactions planned to be added to those groups in the usual way, then reduce those transactions as necessary (e.g. proportionally to weights) if the group's max is exceeded and recurse onto the remaining accounts with the excess.Rather than do it that way, which is likely to make subclassing harder, add handling code at the
__call__level by addingcontribution_group-aware logic to_recurse_minand/or_recurse_max.See #4 for a related issue.