Extending Contracts

[bickelj]

At the moment, the contracts area manages contract documents and signing. We are going to extend contracts to explicitly include the (money) amount a given contract requested and also the (money) amount approved by the funder, and also track disbursements, also views for these in various tables and API calls.

Would y'all accept the two additional (optional) attributes of requested and approved amounts on the actual model, class Contract(models.Model)?

[frjo]

Would y'all accept the two additional (optional) attributes of requested and approved amounts on the actual model, class Contract(models.Model)?

That should not be a problem I think.

We already have SUBMISSIONS_TABLE_EXCLUDED_FIELDS and I was planing to implement PROJECTS_TABLE_EXCLUDED_FIELDS. If you add more project table columns and OTF have plans to add some as well there will be to many to fit on a screen. Hypha will ship with some senible default and each org add/remove whatever they need.

[bickelj]

Good! Heads up that there is a third field needed, currency, to identify the currency used in the contract and qualify the two amounts.

[bickelj]

We have started development on a simplified "Disbursements" flow in projects. See https://code.librehq.com/ots/hypha/-/merge_requests/205 for the current tip of development of this concept (vs ardc-main).

Some of the changes:

• Unconditional re-use of the existing Contract model, extending it with Currency, Requested Amount, and Approved amount.
• Conditional use of a separate Disbursement model that tracks disbursements.
• Conditional many-Contract-per-Project allowance.
• The condition for the above two is a new system setting that defaults to the standard Invoicing flow but can be changed to Disbursements which enables the above and hides the usual Invoicing. There is also an option to disable both.

The idea is that both the flows will be useful to more deployments but should be chosen exclusively. Also it should help with upstreaming/downstreaming to have this feature flag rather than having to nerf or enable capabilities in a fork.

@frjo @wes-otf any thoughts on the above?

[frjo]

I will look at the code but it will take at least another week. Been busy helping a new Hypha implementor.

I see no reasons this could not be part of core Hypha if:

1. Be default it does not disrupts other Hypha users on deployment.
2. The solution is generic enough to be useful for other funds.
3. Clean and neat implementation.

After a quick look I think it looks promising.

[wes-otf]

Also have yet to deep dive on this but will this week! I agree that the initial looks I've take seem nice and could benefit the general codebase!

[bickelj]

I created #4987. It is a quick rebase of the commits we presented to our customer, I didn't want to lose track of the order later. It is not ready (draft) as I haven't even tried it on base hypha yet. I expect we'd do that after we actually ship the feature to the customer.

[bickelj]

@frjo @wes-otf If you were to add an authenticated API endpoint (I guess Hypha used to have those), what package would you use for the authentication system?

[frjo]

Hypha used https://github.com/encode/django-rest-framework plus https://github.com/florimondmanca/djangorestframework-api-key before but all that got removed together with the React app.

Today I would likely look at https://github.com/vitalik/django-ninja if building a bigger API. Only read about it, never used.

For something small I would first try to build it with only Django/Python.

[bickelj]

plus https://github.com/florimondmanca/djangorestframework-api-key

I think at the moment our best option is using djangorestframework-api-key plus a Wagtail config to add/delete keys using this. I hope that sounds palatable enough, I don't think it would require the Wagtail config in order to use, but that should make the keys a bit more user-friendly for the customer.