Add configuration settings for collections subscriptions. (PP-1850)

[tdilauro]

Description

Adds start and end date configuration settings for collection subscriptions.

NB: Submitting this PR as draft, since additional work is needed fully implement the subscription functionality.

• CM Admin UI: support date picker field in configuration forms.
• CM backend: New functionality to use the configuration settings to block libraries from using the collection.

Motivation and Context

Support automatic activation/deactivation of library associations with a collection.

[Jira PP-1850]

How Has This Been Tested?

• Tests pass locally.
• CI tests for associated branch pass.

Checklist

• I have updated the documentation accordingly.
• All new and existing tests passed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.78%. Comparing base (fed3447) to head (c798d51).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2153   +/-   ##
=======================================
  Coverage   90.78%   90.78%           
=======================================
  Files         350      350           
  Lines       40608    40611    +3     
  Branches     8796     8796           
=======================================
+ Hits        36864    36867    +3     
  Misses       2439     2439           
  Partials     1305     1305           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jonathangreen]

Added some comments with a couple questions on this one

[jonathangreen]

Should we be adding these settings for every circulation API? It seems like we only really want them for OPDS importer based APIs.

[tdilauro]

I think they could be handy more generally; but, I'm fine moving them to the OPDS collections setting hierarchy for now.

I'm planning to implement the subscription (vs. association) concept across all collection types, but the absence of these settings on a collection would be interpreted as always subscribed (i.e., no restriction).

[jonathangreen]

Since these are coming in as dates, should we be setting the type here to reflect that, rather then just a generic str?

[tdilauro]

I did try using subscription_activation_date: datetime.date | None = FormField( ... for these, but ran into type errors in Pydantic.

I can dig into that some more as I do the implementation.

[jonathangreen]

I was thinking about this one, and I'm wondering if we want to store the subscription end dates as full datetime. We are going to need a particular time to say a subscription ends, and we will need to think about what timezone that should be in.

A couple options I was thinking about:

• Have the UI allow choosing the date and time the subscription ends
• Choose the date, and use the users timezone to come up with an end datetime that gets sent to the CM
• Allow both selecting a date and the timezone the subscription end should be enforced in

[tdilauro]

I was thinking about this one, and I'm wondering if we want to store the subscription end dates as full datetime. We are going to need a particular time to say a subscription ends, and we will need to think about what timezone that should be in.

My original thought on this was to use UTC to make this easier to manage with the distributors, who might also be enforcing their subscriptions. It would make things simpler. If libraries are able to negotiate a single "grace" day on each end of the subscription.

We could always add an offset later.