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 91.11%. Comparing base (17948cb) to head (ffef549).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2153   +/-   ##
=======================================
  Coverage   91.11%   91.11%           
=======================================
  Files         363      363           
  Lines       41297    41300    +3     
  Branches     8841     8841           
=======================================
+ Hits        37629    37632    +3     
  Misses       2406     2406           
  Partials     1262     1262           

☔ 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.

[tdilauro]

@jonathangreen Would you take another look at this one? Especially the pyupgrade pre-commit exception. If you'd like, I could pull those config settings out into their own module to reduce the surface area of the exception.

[jonathangreen]

I think it would be good to elaborate a bit more about the details of the issue you are working around in pydantic. I added a little test to try to understand what was happening, and it seemed like pydantic was working fine in this instance with a datetime.date | None annotation.

diff --git a/tests/manager/api/admin/test_form_data.py b/tests/manager/api/admin/test_form_data.py
index 1c1a02023..d4a8ad220 100644
diff --git a/tests/manager/api/admin/test_form_data.py b/tests/manager/api/admin/test_form_data.py
index 1c1a02023..d4a8ad220 100644
--- a/tests/manager/api/admin/test_form_data.py
+++ b/tests/manager/api/admin/test_form_data.py
@@ -1,3 +1,5 @@
+import datetime
+
 from werkzeug.datastructures import ImmutableMultiDict

 from palace.manager.api.admin.form_data import ProcessFormData
@@ -46,6 +48,22 @@ class MockSettings(BaseSettings):
             description="Another date.",
         ),
     )
+    field6: datetime.date | None = FormField(
+        None,
+        form=ConfigurationFormItem(
+            label="Another date field with a date type",
+            type=ConfigurationFormItemType.DATE,
+            description="A python date.",
+        ),
+    )
+    field7: datetime.date | None = FormField(
+        None,
+        form=ConfigurationFormItem(
+            label="Another date field with a date type",
+            type=ConfigurationFormItemType.DATE,
+            description="A python date.",
+        ),
+    )


 def test_get_settings():
@@ -59,6 +77,8 @@ def test_get_settings():
             ("field3", "value5"),
             ("field4", "2024-10-23"),
             ("field5", ""),
+            ("field6", "2024-10-23"),
+            ("field7", ""),
         ]
     )
     settings = ProcessFormData.get_settings(MockSettings, data)
@@ -67,3 +87,5 @@ def test_get_settings():
     assert settings.field3 == "value5"
     assert settings.field4 == "2024-10-23"
     assert settings.field5 is None
+    assert settings.field6 == datetime.date(2024, 10, 23)
+    assert settings.field7 is None

[tdilauro]

I think it would be good to elaborate a bit more about the details of the issue you are working around in pydantic. I added a little test to try to understand what was happening, and it seemed like pydantic was working fine in this instance with a datetime.date | None annotation.

@jonathangreen Well, you're right! It is working without errors now. A quick check doesn't show anything pertinent that has changed since this PR first went in, so I'm a little baffled. I had similar params in when I was initially testing this, too. SMH

At any rate, this is ready for another look.

[jonathangreen]

Looks good to me