Bug 37767

Lesson learned: don't try to file multiple near-identical bugs late in the evening, you'll confuse them.

The two forms in Authority types are the cancel button when you decide not to delete a tag, and the search for tags form (there is no confirmation page after deleting a tag).

Sigh.

There is a delete confirm page, and it doesn't show because auth_tag_structure.pl just does a print $input->redirect() and exits after deleting a tag.

The cancel button when you decide not to delete a tag has already been switched to a get.

The copy-pasted but not kept in sync duplicated code between Authority types and MARC bibliographic frameworks is annoying.

The two forms that POST without an op are dead code in the template for a delete confirm page, and the search for tags, which like MARC bibliographic frameworks in bug 37766 should be a GET so you can bookmark or link to searches for a particular tag in a particular framework.

Created attachment 170894 [details] [review]
Bug 37767: Fix forms that POST without an op in Authority types

We intend not to have forms with method="post" without an op variable (so we
can check that the op starts with "cud-" as part of the CSRF protection), but
because of bug 37728 some were missed.

In Authority types, that's dead code in the template that expects to show a
"Data deleted" confirmation page, but it never shows because rather than
setting the variable delete_confirmed and outputting the template, the op
cud-delete_confirmed just does a print $input->redirect() and exits, and, the
search for tags form that should be a GET so it can be bookmarked and linked
to.

Test plan:
 1. Without the patch, Administration - Authority types - choose one other
    than default, so you can see the code rather than "" in the URL -
    Actions - MARC structure
 2. For any tag (you *are* testing in a throwaway database, right?) click
    Actions - Delete then Yes, delete
 3. Note that you don't get a confirmation page, just redirected back to a
    search for your tag which no longer exists, with the searchfield and
    authtypecode nicely in the URL
 4. Click the Search button for the Search for tag form, without changing
    anything
 5. Note that your URL lost the searchfield and authtypecode
 6. Apply patch, restart_all
 7. Repeat steps 1, 2, and 3, with identical results like they should be
 8. Repeat step 4, but this time note that the searchfield and authtypecode
    stay in the URL.
 9. Change the select menu for In framework and click Search, note that
    the searchfield and frameworkcode are still in the URL and still correct
    and that the correct results show
10. Change the tag number and hit Enter, and verify that the URL and the
    page show the correct results

Sponsored-by: Chetco Community Public Library

And yes, after all my confusion about what I was fixing here, I did apply the patch from bug 37728 on top of my patch and verify that xt/find-missing-op-in-forms.t was no longer finding any in auth_tag_structure.tt :)

Created attachment 171216 [details] [review]
Bug 37767: Fix forms that POST without an op in Authority types

We intend not to have forms with method="post" without an op variable (so we
can check that the op starts with "cud-" as part of the CSRF protection), but
because of bug 37728 some were missed.

In Authority types, that's dead code in the template that expects to show a
"Data deleted" confirmation page, but it never shows because rather than
setting the variable delete_confirmed and outputting the template, the op
cud-delete_confirmed just does a print $input->redirect() and exits, and, the
search for tags form that should be a GET so it can be bookmarked and linked
to.

Test plan:
 1. Without the patch, Administration - Authority types - choose one other
    than default, so you can see the code rather than "" in the URL -
    Actions - MARC structure
 2. For any tag (you *are* testing in a throwaway database, right?) click
    Actions - Delete then Yes, delete
 3. Note that you don't get a confirmation page, just redirected back to a
    search for your tag which no longer exists, with the searchfield and
    authtypecode nicely in the URL
 4. Click the Search button for the Search for tag form, without changing
    anything
 5. Note that your URL lost the searchfield and authtypecode
 6. Apply patch, restart_all
 7. Repeat steps 1, 2, and 3, with identical results like they should be
 8. Repeat step 4, but this time note that the searchfield and authtypecode
    stay in the URL.
 9. Change the select menu for In framework and click Search, note that
    the searchfield and frameworkcode are still in the URL and still correct
    and that the correct results show
10. Change the tag number and hit Enter, and verify that the URL and the
    page show the correct results

Sponsored-by: Chetco Community Public Library
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>

Created attachment 171537 [details] [review]
Bug 37767: Fix forms that POST without an op in Authority types

We intend not to have forms with method="post" without an op variable (so we
can check that the op starts with "cud-" as part of the CSRF protection), but
because of bug 37728 some were missed.

In Authority types, that's dead code in the template that expects to show a
"Data deleted" confirmation page, but it never shows because rather than
setting the variable delete_confirmed and outputting the template, the op
cud-delete_confirmed just does a print $input->redirect() and exits, and, the
search for tags form that should be a GET so it can be bookmarked and linked
to.

Test plan:
 1. Without the patch, Administration - Authority types - choose one other
    than default, so you can see the code rather than "" in the URL -
    Actions - MARC structure
 2. For any tag (you *are* testing in a throwaway database, right?) click
    Actions - Delete then Yes, delete
 3. Note that you don't get a confirmation page, just redirected back to a
    search for your tag which no longer exists, with the searchfield and
    authtypecode nicely in the URL
 4. Click the Search button for the Search for tag form, without changing
    anything
 5. Note that your URL lost the searchfield and authtypecode
 6. Apply patch, restart_all
 7. Repeat steps 1, 2, and 3, with identical results like they should be
 8. Repeat step 4, but this time note that the searchfield and authtypecode
    stay in the URL.
 9. Change the select menu for In framework and click Search, note that
    the searchfield and frameworkcode are still in the URL and still correct
    and that the correct results show
10. Change the tag number and hit Enter, and verify that the URL and the
    page show the correct results

Sponsored-by: Chetco Community Public Library
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Pushed for 24.11!

Well done everyone, thank you!