1346 create recap pray and pay

[v-anne]

This pull request implements the backend for #1346, the RECAP pray and pay project. It incorporates a few functions that (1) enforce the quota for users for maximum document requests each day, (2) that add document requests to the Prayer model, and (3) then update document requests after they are satisfied.

This is a work in progress and is just part of the MVP. Other features such as email notifications will come later.

[v-anne]

At least two issues right now before this is ready for review.

1. Not 100% sure which file in the settings directory to define the environment variable ALLOWED_PRAYER_COUNT.
2. Not sure how to write the tests yet when this PR is only for the backend and the frontend isn't ready yet.

Would appreciate @mlissner's thoughts.

[mlissner]

The var can go in misc.py or in project/prayers.py. I think the former is better until we have three or more settings for it.

There are whole books on your second question, but I think I'd fakers to make a user and some prayers, and then I'd make some little tests to make sure my functions are working properly. This barely needs tests, I agree, but you could check that the ranking is right and that people properly run out of prayers. You could also use time machine to play with the 24 hour timer?

[v-anne]

There are whole books on your second question, but I think I'd fakers to make a user and some prayers, and then I'd make some little tests to make sure my functions are working properly. This barely needs tests, I agree, but you could check that the ranking is right and that people properly run out of prayers. You could also use time machine to play with the 24 hour timer?

Does this require me to be able to run the Docker container and everything else locally? I had issues with it the last time I tried so it might take me some time to manage it.

[mlissner]

You could rely on Github actions to run the tests, if you want. Might be slow to iterate, but I suppose it'd work.

[v-anne]

@mlissner I'm attempting to create some dummy data with Faker. I'm running into some issues, however. The code I just pushed was an attempt to create data for the Prayer model, which is dependent on there being data in the RECAPDocument model. I ran docker exec -it cl-django python /opt/courtlistener/manage.py make_dev_data, like the guide suggests doing, but neither model has any data in it after checking via the Django shell. Any thoughts? Other models like User do have dummy data after running this command, so any issue is likely limited to those two models.

EDIT: disregard this for now, I think I figured out my issue.

[v-anne]

I'm going to confess error, @mlissner. Not sure how to solve the issue above.

[mlissner]

@v-anne, sorry to leave you hanging. @albertisfu, do you think you could find a minute to help Vijay get their tests working?

[mlissner]

(Just FYI, Vijay, Alberto has a few other things in his queue before this one, sorry!)

[v-anne]

No worries, Mike. In the interest of time, I will try to work on the front end so it can be included in this PR too.

[v-anne]

Just pushed a rough front end, I'm going to hold off on making any substantial changes to any of this until @albertisfu has a chance to weigh in. I think this PR is 85% of the way there, if Alberto can identify what the issues are with the fakers for the Prayer and RECAPDocument models, I'll be able to fully test and then have a finalized PR.

[v-anne]

Started discussion #4459

[albertisfu]

@mlissner @v-anne I've applied the following changes:

• Moved the prayer methods to cl.favorites.utils and made them async.
• Added tests for the prayer methods.
• Added an integration test that changes the status of related Prayer instances when a document is granted.
• Fixed the create_prayer method so that all tests pass.
• Made the following adjustments to the get_top_prayers query:
  • Only checks for RECAPDocuments that have a related Prayer, as it was previously checking every RECAPDocument in the database.
  • Returns only the fields required to display on the leaderboard and create the PACER document URL.
• Improved the leaderboard template:

The HTML now looks like this:

I'm wondering which fields we need to display here and if a link to PACER is required?

I have a question:

Is it possible for a user to pray for the same RECAPDocument multiple times? Or should there be only one prayer per user per document? If it's the latter, we might need to add a unique constraint to the model and tweak the prayer_eligible method.

Is there anything else I can help with?

[mlissner]

This looks good to me with a few little things.

Thanks Alberto for your work and review! Your comments all sounds great.

Is it possible for a user to pray for the same RECAPDocument multiple times? Or should there be only one prayer per user per document? If it's the latter, we might need to add a unique constraint to the model and tweak the prayer_eligible method.

Good point. Yes, we'll want to do that.

I'm wondering which fields we need to display here and if a link to PACER is required?

We've got a lot of work to do on that, but I think we can launch it as an MVP now, right?

[v-anne]

Alberto, thank you so much for your work on this. My responses are below.

I'm wondering which fields we need to display here and if a link to PACER is required?

I think this is alright for this PR. It will need some changes but this PR currently doesn't allow users to actually add prayers from the front end yet, so it's ok if it's not perfect.

I have a question:

Is it possible for a user to pray for the same RECAPDocument multiple times? Or should there be only one prayer per user per document? If it's the latter, we might need to add a unique constraint to the model and tweak the prayer_eligible method.

I agree with Mike. It was not my attention to allow that. Accordingly, I added a constraint to the Prayer model and adjusted the create_prayer method to prevent one user requesting the same document multiple times.

Is there anything else I can help with?

I think the last thing needed before this PR can be merged is to figure out why the test suite is failing after the migration is applied.

Again, thank you for revising the issues with my code.

[mlissner]

Looking good! It looks like you're missing the migration file and that's why tests are failing.

[v-anne]

I think it's good to go now.

[albertisfu]

@v-anne I reviewed your changes. They look good. I just made a small tweak to the create_prayer method to simplify it and added a related test.

I also added the SQL migration file for the unique constraint migration.

Finally, I have a question about whether the open_prayers view should be private or not.

Thanks!

[albertisfu]

@mlissner If there are no more comments from your side, I think this could be merged. It will require applying the migration on prod.

[mlissner]

Merged! Thank you both! I'll get it deployed in a moment, over here: https://github.com/freelawproject/courtlistener/actions/runs/11002188561

[mlissner]

We're in business! https://www.courtlistener.com/prayers/top/

[mlissner]

I mean, sort of!