Admin UI: Print and Export-To-PDF buttons fail (either showing no applications or showing too many).

[PaulMorris]

Summary:

• Print button in service admin applications tables (under enrollments) shouldn't fail
• Export to PDF button in service admin applications tables (under enrollments) shouldn't fail
• Remove the checkboxes on the applications tables (for both provider and service admin), or let them have some effect like limiting what shows up in the PDFs and print screens.

Log in as a service admin, go to the applications tables under "ENROLLMENTS", then select some checkboxes and click the print button at the top of the table. Always see a page that says no results are found (service_agent_print_enrollments.jsp).

Do the same thing on the search results pages (advanced or quick) and you see a page with a list of all the applications, not just the ones you checked.

Similar results occur for "Export to PDF" button. On the ENROLLMENTS pages you get an empty PDF, and on the search results pages you get a PDF with all the applications listed.

When logged in as a provider, on the ENROLLMENTS pages you can successfully export a pdf that lists all the applications for the current status (Draft, Pending, etc.), the checkboxes have no effect. On the search results pages it is the same as for an admin, you get a pdf or a printable screen with all the applications, regardless of checked boxes.

So it seems then that the checkboxes in these tables currently serve no purpose. I was assuming they would affect the output of those buttons, but that is not the current behavior.

[slifty]

Those checkboxes have the enrollmentRowCheckBox class ... which seem to be ONLY used in an admin script method called renewSelections ... which seems to ONLY be called from buttons in the enrollment_buttons.jsp include

The enrollment_buttons.jsp template is not loaded from the enrollment_search_results_table.jsp (the relevant template here).

Rather than bend the check-box infrastructure, I'm inclined to remove them from this section. meta point: this instinct reflects the fragility of the "monolithic script file" approach that exists for PSM. If this project ever undergoes a frontend refactoring / re-implementation we would probably be well served by considering a more modular framework such as React or Vue to define these kinds of interfaces in self-contained / re-usable packages.

I'm still looking into the print / export to PDF buttons and what functionality we should implement there. It may be that after looking I will come back and change my tune about these checkboxes (though it still feels fragile to have these functional couplings across otherwise separate UIs)

[slifty]

The plot thickens.

The checkboxes are used on this view, but only when the user has narrowed down to the "Approved" tab -- which has an extra button that says "renew selected enrollments."

Simply removing the checkboxes would break that functionality. This means we either need to:

A) only show checkboxes when viewing the "approved" tab contents. B) make the checkboxes useful on other tabs as well.

[slifty]

It looks like the root cause for the broken Print / Export buttons is the following block in the setupSearchFormCriteria method in script.js:

if ($("#requestTypeInput").val() != '') {
        $('#searchForm').append('<input name="requestTypes[0]" value="' + $("#requestTypeInput").val() + '" type="hidden" />');
      }

      if ($("#riskLevelInput").val() != '') {
        $('#searchForm').append('<input name="riskLevels[0]" value="' + $("#riskLevelInput").val() + '" type="hidden" />');
      }

Specifically, #requestTypeInput is not an actual entity (and it's .val() is undefined, which is != '').

Not to sound like a broken record, but this bug is a manifestation of the way we have a monolithic script file, with hard-coded references to specific elements! I suspect that at some point we changed the naming of requestTypeInput (it is now enrollmentSearchFilterRequestTypeInput) but this method was not updated to reflect that change (understandable, because there is no way to really know it would affect this code!).