Skip to content

Conversation

@joepaolicelli
Copy link
Contributor

Resolves #4985.

Please note I have only intermittently worked with Ruby for the past several years, so apologies in advance for any mistakes due to that. The amount of code changed here is minimal, and I did my best to base it on similar code from elsewhere in the codebase. I ran bin/lint and no issues were detected.

Description

Applies filters to the printable "Unfulfilled Picklists" PDF, instead of always printing every request. Also updates the count shown on the "Print Unfulfilled Picklists".

Type of change

  • Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I've added a test to ensure the "Print Unfulfilled Picklists" button shows the correct quantity when filters are applied. However, I was unable to determine how to add a test to check if the correct number of pages are created in the PDF, or if the testing framework was even set up to allow that. Instead, I manually tested several different configurations of filters to ensure that they led to only the expected filtered requests being including in the PDF.

Screenshots

image

@cielf
Copy link
Collaborator

cielf commented Apr 11, 2025

@dorner, @awwaiid Do you have any wisdom to give on how to check that the correct number of pages are generated in a PDF? / If we do that?

@cielf cielf self-requested a review April 11, 2025 18:56
Copy link
Collaborator

@cielf cielf left a comment

Choose a reason for hiding this comment

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

Functionality looks good! Over to @dorner or @awwaiid for technical review.


get requests_path(request), params: params

expect(response.body).to include('Print Unfulfilled Picklists (1)')
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is a bit of a sideways way of testing that the filters work - I'd expect to check that the response body includes the picklist that is returned and not the one that's filtered out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test is explicitly meant to test that the value shown in the button text is correct, not that filters as a whole work. The filters working to filter the results shown within the app already worked, and so I'm not trying to test that since it's not part of the issue this PR is trying to solve.

However, having the results filtered in the downloaded PDF is part of this issue - I'm just not sure how to test that, as noted in the original PR comment.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you get some more information out of this response? It's not really testing which data is being rendered, only that there's 1 of them.

@joepaolicelli
Copy link
Contributor Author

Thanks for the feedback @dorner! I've simplified the test (filtering on status instead of partner organization) in a way that I think solves your concerns and also fixes some other issues I found. If you approve of the updates and my responses to your comments, I think the only remaining issue is if/how to test the PDF output, as discussed above.

@dorner
Copy link
Collaborator

dorner commented Apr 22, 2025

@joepaolicelli
Copy link
Contributor Author

Thanks @dorner, that file looks like it might be the right strategy for the most robust test of this PR. Unfortunately is looks like it is only set up to work with distribution PDFs, not picklists PDFs, and I don't think I'd be the right person to figure out how to adapt/copy that strategy for picklist PDFs.

Since previous work on the picklist page didn't include tests that compared against the generated PDFs, I'm not sure if they're needed for this PR, but if they are perhaps we put this change on hold until someone more familiar with the codebase and RSpec can work on that.

@dorner
Copy link
Collaborator

dorner commented May 2, 2025

I think we do need to validate the results in the PDF. If you don't think you'll be able to do that kind of work, I'd rather bump the difficulty for this up to Intermediate and reopen it.

@cielf
Copy link
Collaborator

cielf commented May 3, 2025

Thank you for the solid start, @joepaolicelli! Per your wishes, I have re-"Help Wanted" the issue so we can get someone with the particular skills needed to work on it.

joepaolicelli and others added 5 commits September 13, 2025 16:02
- Generate the pdf and add to fixture
- Rename content in PDFComparisonTestFactory to be more domain specific
- Add compare_pdf to spec to compare the file to the
@jonny5 jonny5 force-pushed the 4985-print-filtered-picklists branch from 953a54c to d62f919 Compare September 13, 2025 20:04
@jonny5
Copy link
Collaborator

jonny5 commented Sep 17, 2025

@dorner I added the PDF test if you want to take another look

Copy link
Collaborator

@dorner dorner 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 - had one last suggestion.


get requests_path(request), params: params

expect(response.body).to include('Print Unfulfilled Picklists (1)')
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you get some more information out of this response? It's not really testing which data is being rendered, only that there's 1 of them.

@jonny5
Copy link
Collaborator

jonny5 commented Sep 20, 2025

@dorner updated spec to check for comments from request in body, that seem good?

get requests_path({ filters: { by_status: :started} })

expect(response.body).to include('Print Unfulfilled Picklists (1)')
expect(response.body).to include(started_request.comments)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please use the actual string that's expected - whenever possible, expected results should not be calculated.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok updated

@jonny5 jonny5 force-pushed the 4985-print-filtered-picklists branch from 6348698 to a3c66f7 Compare September 22, 2025 16:11
Copy link
Collaborator

@dorner dorner left a comment

Choose a reason for hiding this comment

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

Technical review looks good - over to @awwaiid for functional.

@dorner dorner requested a review from awwaiid September 26, 2025 19:52
Copy link
Collaborator

@awwaiid awwaiid left a comment

Choose a reason for hiding this comment

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

Functional review all checks out!

@awwaiid awwaiid merged commit 86509b1 into rubyforgood:main Sep 28, 2025
16 of 17 checks passed
@github-actions
Copy link
Contributor

github-actions bot commented Oct 5, 2025

@joepaolicelli: Your PR Resolves #4985: Picklists should be filterable is part of today's Human Essentials production release: 2025.10.05.
Thank you very much for your contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Picklists should be filterable

5 participants