Just using this as an example because it appears in many places on the intranet Is there a reason that we navigate to a new page to confirm or cancel a delete rather than just using a Javascript confirm message? A JS message would use much less code. I realise that in the past we had a rule that everything had to work without JS enabled but a lot of stuff on the intranet wouldn't work at all without JS so I'm not sure how much that applies anymore. Anyway, just wondering if these extra pages for confirm or cancelling a delete are still necessary or if we can do this via JS now :)
I think a lot of the administration configuration pages follow this pattern.
There are times when it's useful, but not very many, and not very useful. For example, deleting a bib framework, the confirm page either says "Confirm deletion of framework 'Kits' (KT)?" or "This framework cannot be deleted Serials (SER) The framework is used 21 times." Though actually that isn't as useful as it seems, since all you have to do is open the confirm page at a time when the framework is unused, not click the confirm button at a time when it is unused. If someone creates a KT record between when you load the confirmation page and when you click Yes, delete then the framework is deleted and that record is in an undefined framework. There's the alternative authority record model, where you only get a Delete button in authority search results if it is unused at the time you load the page, though that's less obvious at getting across "you can delete this, but only if you first make it unused," and it also suffers from the same problem of only requiring that you load a page while something is unused, not that it be unused at the time you actually delete.
Btw I was just looking at giving some info on bug 38378 about CSRF and deletes, and in some ways the confirm delete pages make it easier to do CSRF friendly deletes without requiring additional Javascript.
That being said, /cgi-bin/koha/admin/record_sources uses a modal, which works just as well if not better. That is, I don't think using Javascript is bad. Yay Javascript! Rather, using a confirm_delete lets us avoid constructs like we need for these commits: commit 5d3b7cf08949d5776b732f24cefcbe377260c281 commit 47d6725a722728c5d0ae38953a0d8c74d99d3d9e
Ah, but then Owen shows us a better way with commit 7dc1b9e95436452d2008bce17aa88df6496064a6