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 tools/letter.tt that's two forms, https://git.koha-community.org/Koha-community/Koha/src/commit/4f524635516325bfe6b56ddf96476c03086956b6/koha-tmpl/intranet-tmpl/prog/en/modules/tools/letter.tt#L552 which is shown IF ( add_validate or copy_validate) and one a bit further down at #L594 which is shown IF ( delete_confirmed ). To someone that knows how are templates work, that would sound like either the op which wants to show them would be add_validate or copy_validate or delete_confirmed, or more likely in the current era it would be cud-add_validate etc., which either sets the param add_validate, or was broken by the change to cud-ops. These two are different, though. If you look back through blame history for every change to letter.pl for the ops in question, they have never, ever, let their op be defined for a template to show a confirmation message. Currently they do "$op = q{}; # we return to the default screen for the next operation", if you go back to the dawn of time, prior to rel_3_0 moved to HEAD, they started out doing "print $input->redirect("letter.pl");". I'd like to have a better term than "dead code" for something which has been unreachable since it was copy-pasted from some other template, but I can't come up with an inoffensive one.
Created attachment 170899 [details] [review] Bug 37785: Remove dead code in tools/letter.tt that looks like a form that would POST without an op 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. The two in tools/letter.tt are blocks of never-used code which would display a message confirming that you saved a notice, or that a notice was deleted after you confirmed that you wanted to delete it, but neither one has ever been executed. Now, the names of the ops don't match, because they are cud-add_validate etc. and would have to explicitly set a param for add_validate, but even before the CSRF change to cud- ops, they explicitly unset their $op so that as they say "# we return to the default screen for the next operation". Prior to that, they just did "print $input->redirect("letter.pl");" No test plan is possible, since this code has never once done anything. Sponsored-by: Chetco Community Public Library
Hum, yes... Better to fix the confirmation messages but I do agree it's out of the scope of this bug.
Created attachment 170959 [details] [review] Bug 37785: Remove dead code in tools/letter.tt that looks like a form that would POST without an op 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. The two in tools/letter.tt are blocks of never-used code which would display a message confirming that you saved a notice, or that a notice was deleted after you confirmed that you wanted to delete it, but neither one has ever been executed. Now, the names of the ops don't match, because they are cud-add_validate etc. and would have to explicitly set a param for add_validate, but even before the CSRF change to cud- ops, they explicitly unset their $op so that as they say "# we return to the default screen for the next operation". Prior to that, they just did "print $input->redirect("letter.pl");" No test plan is possible, since this code has never once done anything. Sponsored-by: Chetco Community Public Library Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Created attachment 171266 [details] [review] Bug 37785: Remove dead code in tools/letter.tt that looks like a form that would POST without an op 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. The two in tools/letter.tt are blocks of never-used code which would display a message confirming that you saved a notice, or that a notice was deleted after you confirmed that you wanted to delete it, but neither one has ever been executed. Now, the names of the ops don't match, because they are cud-add_validate etc. and would have to explicitly set a param for add_validate, but even before the CSRF change to cud- ops, they explicitly unset their $op so that as they say "# we return to the default screen for the next operation". Prior to that, they just did "print $input->redirect("letter.pl");" No test plan is possible, since this code has never once done anything. Sponsored-by: Chetco Community Public Library Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Pushed for 24.11! Well done everyone, thank you!