Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ODL availability proposal (PP-869) #1903

Merged
merged 8 commits into from
Jun 18, 2024
Merged

Conversation

jonathangreen
Copy link
Member

@jonathangreen jonathangreen commented Jun 13, 2024

Description

This will require ThePalaceProject/webpub-manifest-parser#170 to be merged, and our poetry dependencies to be updated before merging. The palace-webpub-manifest-parser dependency is temporarily pointing at a branch to make it easier to test.

This PR moves the time_tracking property that was overridden by a custom class in Palace, back out into the webpub-manifest-parser, and adds support for the draft ODL Availability (removals) proposal here: opds-community/drafts#63

Motivation and Context

JIRA: PP-869

This is the first round of work on this. It does not address several cases that were mentioned in the tech strategy meeting last week:

  • Removing existing loans / hold for works that become unavailable
  • Including the availability status in the crawlable feed from the CM

My thinking in that these can be handled in follow up tickets, since this PR solves the immediate need to be able to have items removed from feeds, and now show up as available for new loans.

How Has This Been Tested?

  • Tested in CI

Checklist

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

@jonathangreen jonathangreen added the feature New feature label Jun 13, 2024
@jonathangreen jonathangreen force-pushed the feature/odl-feed-removals branch from 85a37db to 031d890 Compare June 13, 2024 19:08
Copy link

codecov bot commented Jun 13, 2024

Codecov Report

Attention: Patch coverage is 90.74074% with 5 lines in your changes missing coverage. Please review.

Project coverage is 90.28%. Comparing base (ed8826f) to head (b0e4462).

Files Patch % Lines
src/palace/manager/api/odl2.py 87.80% 1 Missing and 4 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1903      +/-   ##
==========================================
- Coverage   90.28%   90.28%   -0.01%     
==========================================
  Files         332      332              
  Lines       39873    39868       -5     
  Branches     8649     8652       +3     
==========================================
- Hits        36001    35996       -5     
  Misses       2577     2577              
  Partials     1295     1295              

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

@jonathangreen jonathangreen requested a review from a team June 17, 2024 12:16
Copy link
Contributor

@tdilauro tdilauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! 🎸

Definitely no showstoppers here, but couple of comments for your consideration. 🤔

available = opds2_ast.OPDS2AvailabilityType.AVAILABLE.value
if (
availability
and availability.state != available
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an availability property is present here, should we also consider the since date/time, if present? The discussion as of the end of late March left this unresolved. Is the availability property in effect if the since date/time has not yet arrived?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because since implies past tense, I'm assuming that it is in the past. So since is just informational in the feed. Hadrien seemed strongly against since giving a state change in the future on the OPDS call.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add a check that we fall within the range since -> until if you think that makes more sense. I was just basing the behaviour upon the discussion in the OPDS working group call.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I'm not super happy with where we left that discussion and don't find compelling the arguments against representing future availability. That said, I agree with your other comment that we don't have enough information for other behavior.

Hadrien's comments there seem to imply that availability.since is, at best, informational (it shouldn't be actioned on for a future change); so, perhaps it is best not to use it in any logic for now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I called out that since isn't used in my new comment, and I added a todo to revisit how we handle since once there is some resolution of your question here opds-community/drafts#63 (reply in thread)

cls, availability: opds2_ast.OPDS2AvailabilityInformation | None
) -> bool:
"""Extract the publication's availability from its availability information.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is our stance here that, if an availability is present, but we are past the until date/time, that we simply act as if the availability prop is not present and then just use the default availability behavior?

Might be worth a comment in the docstring here.

Also might be worthwhile to to have a DEFAULT_AVAILABILITY (True for our current behavior) and distinguish between an active availability property and the default more explicitly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is what my assumption is here. I'll add a doc comment to make it more explicit. I don't think we have enough information for any other behaviour, since we don't have any indication of what the future state would be.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that makes sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a more detailed comment on the _extract_availability function.

@jonathangreen jonathangreen force-pushed the feature/odl-feed-removals branch from 51b17ef to c707399 Compare June 18, 2024 13:51
@jonathangreen jonathangreen marked this pull request as ready for review June 18, 2024 13:52
@jonathangreen jonathangreen merged commit 3f74425 into main Jun 18, 2024
20 checks passed
@jonathangreen jonathangreen deleted the feature/odl-feed-removals branch June 18, 2024 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants