Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nicolas Hunstein <nicolas.hunstein@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan
1. Go to the staff client
2. Go to administration
3. Search systempreferences for 'StaffInterfaceLanguages'
4. Ensure there is a systempreference variable matching 'StaffInterfaceLanguages'
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nicolas Hunstein <nicolas.hunstein@bsz-bw.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We were missing a couple of TT filters and we were using a `$raw` where it
was more appropriate to use `html`.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes issue introduced by BZ32530
Test Plan (on main):
1 - Edit a patron
2 - Do not change anything and submit -> you get an error
3 - Apply both patches
4 - Repeat 1&2 -> everything works fine
5 - Try and delete the guarantor -> it will be deleted
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes issue introduced by BZ32530
Test Plan (on main):
1 - Edit a patron
2 - Do not change anything and submit -> you get an error
3 - Apply both patches
4 - Repeat 1&2 -> everything works fine
5 - Try and delete the guarantor -> it will be deleted
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the order search form to the Acquisitions home page.
I've modified acqui-home.pl so that it will pass the same default date
limiters as histsearch.pl.
To test, apply the patch and go to Acquisitions.
Test the order search form to confirm that it works as expected. Any
search from this version of the form should return identical results to
seraches performed from the "Advanced search" link in the sidebar.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch corrects the class which is added to the serial prediction
pattern in order for it to display as a second column in the
subscription edit page. "col-xs-*" classes no longer exist in Bootstrap
5.
To test, apply the patch and go to Serials.
1. Click "New subscription"
2. Enter a record number in the form (e.g. 55)
3. Click "Next" (and confirm there is no vendor)
4. Enter values for
- First issue publication date
- Frequency
- Subscription length
- Subscription start date
- Numbering pattern
- Numbering "Begins with"
5. Click "Test prediction pattern"
- The prediction pattern panel should appear as a second column on
the page.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adjusts the CSS of elements in the OPAC header so that menu
items are correctly aligned with various combinations of the OpacPublic
and OpacLangSelectorMode system preferences.
To test, apply the patch and rebuild the OPAC CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client)
- View the header menu in the OPAC with these combinations of settings:
- OpacPublic = On; OpacLangSelectorMode = Top;
- OpacPublic = On; OpacLangSelectorMode = Footer;
- OpacPublic = Off; OpacLangSelectorMode = Top;
- OpacPublic = Off; OpacLangSelectorMode = Footer;
- With each configuration, test that the elements in the header (Logo,
Cart/List menu, Language selctor, and user menu items) align
correctly. The Cart/List menu items should always align to the left,
the Language selector and user menu should aways align to the right.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The template for RSS and Atom feeds of search results (curiously named
opac-opensearch.tt) is careful to escape ampersands in the query_cgi param
while adding it to URLs, but doesn't escape the limit_cgi param at all. It
should.
Two drive-by fixes for Atom: because the <title> when your search has a limit
includes , which isn't an XML character entity, you couldn't get as far
as the error from the <link> URL, and as long as I was going to have blame for
the line, I couldn't bear to leave the stray undefined SEARCH_RESULT. in the
(hard-coded and bogus) <link rel="last">.
Test plan:
1. In the OPAC, Advanced search - check the boxes to limit by item type Books
and Mixed Materials and search for the keyword Perl
2. At the top of the search results, click the orange RSS icon
3. That gives you an ugly "not well-formed" error, so in the URL for the page
change the final "format=rss" to "format=atom"
4. That gives you an ugly "undefined entity" error, so apply the patch
5. Reload the page with the Atom feed, it should change from an error page
to a garbled display of the feed. Click Back to go back to the RSS feed
and reload it if it's still cached on the error page. That should give
a pretty-printed display of the RSS feed without parsing errors
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>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Tools -> Rotating collections -> New collections
2. Add a title and description
3. After adding the new collection notice the breadcrumb isn't right
4. Apply patch
5. Repeat steps 1 and 2
6. After adding the new collection notice the breadcrumb is improved.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch corrects an error where the SQL editor screen would appear
after the report results when using 'Update and run SQL' when editing
reports.
This also corrects a related issue where the saved_sql.id of the report
would be repeatedly appended to SQL code when using 'Update and run
SQL'.
To test:
1) Login to staff client
2) Navigate to Reports -> Create from SQL
3) Create a short report (SELECT * FROM items), name it and SAVE it.
4) On the resulting "Edit SQL report' page, click 'Update and run SQL'
5) See the report runs, but at the 'Edit SQL report' screen shows at the
bottom.
6) Apply Patch
7) Return to Reports -> Saved Reports and Edit the report you created.
8) On "Edit SQL report' page, click 'Update and run SQL'
9) Verify that the report runs, but the 'Edit SQL report' section is
gone.
Sponsored-by: Westlake Porter Public Library
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We were adding "XXX" that was replaced with "999" before the move to the atomic update files (bug 13068).
We do no longer need this code.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The vendor contract management page has a few sections of code that are
meant to display a minimal confirmation message ("Data recorded") after
saving a new or edited vendor contract.
However, aqcontract.pl redirects back to the vendor details page after
saving, so this code is never reached and should be removed.
Test plan:
1. Apply patch
2. Go to the Acquisitions module and find a vendor
3. Click + New > Contract
4. Fill in the information and click Save
5. Click the "Contracts" link in the navigation menu on the left
--> Confirm that the contract was saved correctly
6. Click the Edit button and make changes to all fields
7. Save the information and click "Contracts" again
--> Confirm that the new information saved correctly
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes a few templates which I had missed, including some
which simply had the wrong classes (instead of getting the wrong class
from the perl script).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Many pages can have alerts that get their style from a variable passed
by the script, e.g.:
push @messages, { type => 'message', code => 'success_on_update' };
Rather than change these to match Bootstrap 5 styles, I propose we add a
copy of the existing Bootstrap style using the existing vocabulary:
message -> info
alert -> warning
error -> danger
To test, apply the patch and rebuild CSS for the staff interface and
OPAC: (https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_interface)
- Clear your browser cache if necessary.
- Navigate to pages which have been updated by this patch. Many pages
will implement this kind of alert after saving an edit, especially
administration pages, e.g.
Administration -> Libraries -> Edit library -> Save.
- You can test the various alert classes by adding this HTML to
IntranetMainUserBlock and OpacMainUserBlock and viewing the staff
interface and OPAC main pages.:
<div class="alert alert-danger">A standard Bootstrap danger alert with
<a href="#" class="alert-link">an example link</a>.</div>
<div class="alert alert-warning">A standard Bootstrap warning alert with
<a href="#" class="alert-link">an example link</a>.</div>
<div class="alert alert-info">A standard Bootstrap info alert with
<a href="#" class="alert-link">an example link</a>.</div>
<div class="alert alert-error">A Koha error alert with
<a href="#" class="alert-link">an example link</a>.</div>
<div class="alert alert-alert">A Koha alert alert with
<a href="#" class="alert-link">an example link</a>.</div>
<div class="alert alert-message">A Koha info alert with
<a href="#" class="alert-link">an example link</a>.</div>
Sponsored-by: Athens County Public Libraries
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The OPAC language menu is now generated by the same include file in both
the header and the footer. We have a switch for the menu's direction
based on this context, but we also need a switch for alignment: The menu
should extend left into the page from the header, and right into the
page from the footer.
To test you should have at least one additional language installed and
enabled. To reproduce the bug I recomment en-GB because the language
description is long enough to trigger the misalignment.
- Apply the patch and set the 'opaclanguagesdisplay' system preference
to "Allow" and the 'OpacLangSelectorMode' preference to "both top and
footer".
- Go to the OPAC and test the language selector menus in the header and
footer.
- The expanded menu in the header should extend to the left of the
"Languages" menu trigger.
- The expanded menu in the footer should extend to the right of the
"Languages" menu trigger.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch corrects the logic around how the OPAC language menus are
displayed. Because the footer and header lanugage menus have been
combined into one, the logic for whether the menu should appear has to
live outside the include. The patch also makes corrections to ensure
that the footer menu appears even if the footer language menu is hidden.
NOTE: This patch contains whitespace changes, so please view the diff
accordingly.
To test you should have at least one additional language installed.
- Apply the patch and make sure the OPACLanguages system preference has
more than one language checked.
- Set opaclanguagesdisplay to "Allow."
- In the OPAC, test that the various settings of the
OpacLangSelectorMode preference work correctly (only top, only footer,
both top and footer).
- Test with OPACReportProblem on and off, and CookieConsent on and off.
- Test with OPACReportProblem or CookieConsent enabled and
opaclanguagesdisplay disabled.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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.
There are two in tags/review.tt: the filters for term, status, reviewer, and
dates, which are better as a GET since you can then bookmark and link to a
particular set of filters, and the no-JavaScript fallback for checking whether
a term has been approved or rejected, which currently doesn't work at all,
but with a working op param then works just fine as a GET.
Test plan:
If you have to use Chrome, you're on your own for the disabling JavaScript
and getting rid of the body {display: none !important} style rule, my plan
uses Firefox's devtools to do it
1. Without the patch, Tools - Tags - change the filter from the default
status "pending" to "all", Apply, and bookmark the page
2. Open your bookmark, note that it's status "pending"
3. You can't test the no-JS fallback for term testing since it doesn't
work, so apply patch and restart_all
4. Tools - Tags - change the filter from the default status "pending"
to "all", Apply, and bookmark the page
5. Open your bookmark, note that it's status "all"
6. You need a couple of tags to test the Test feature, so open the OPAC,
log in, search for any record and add the tags approveme, rejectme
7. Back in Tools - Tags, click the Reject button to reject rejectme
8. In the Check lists input, test that approveme shows "approveme is
permitted!" and rejectme shows "rejectme is prohibited!"
8. Now to disable JavaScript, open Firefox's More tools - Web Developer
Tools. You're going to need the Style Editor, so if it's not visible
you'll want to enable it in Settings in the next step
9. Top bar, right side, there's a three-dots menu, with an option for
Settings. In Advanced settings, click the checkbox for Disable JavaScript
(which as hovering the * says, is only for that tab and only until you
close the tab or the toolbox).
10. Checking Disable JavaScript turned your page to blank white, so go to
the Style Editor, where the first thing, already selected, is an inline
style sheet with the rule "body {display: none !important}" - select all
the text of the rule and delete it, which you'll have to do on every
page load
11. In the Check lists input, test that approveme still shows "approveme
is permitted!" (after you delete the display: none !important rule, and
with a rather annoying message about "Tested 1 Term(s)." replacing the
list of terms).
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>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The hidden form that the OPAC uses for downloading a list has no need to be
a POST, which is good because it can't be one without having an op param
that starts with "cud-" which it doesn't have.
Test plan:
1. Nothing visible will change, so start with the patch applied
2. Log in to the OPAC, then do a search for something like Perl which will
return a couple of results. Select two, With selected titles: Add to
list - New list - give it a name and Save
3. Lists - choose the one you just created
4. Download - ISBD
5. Verify that the page you were on didn't change, that a file was downloaded,
and that the file contains the two titles in your list
Sponsored-by: Chetco Community Public Library
Signed-off-by: Chloe Zermatten <chloe.zermatten@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Rather than having a form that does a POST (without an op, which isn't proper),
the final step in changing your password in the OPAC should just be a link.
Test plan:
1. Without the patch applied, log in to the OPAC as a user that you don't
mind changing the password for
2. Welcome, {username} - Your account - Change password
3. Type the old password, and a new password twice, click Change password
4. Below the success message is a green button with white text, Return to
my account - click it
5. Apply patch
6. Change password, type the (new) old password, and a (newer) new password
twice, click Change password
7. Below the success message is what looks like a green button with white
text, Return to my account
8. Hover the button, check your browser status bar for a URL showing you
that it's now a link. Click it to be sure it works.
Sponsored-by: Chetco Community Public Library
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Amended-by: Jonathan Druart
Edited commit message
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch corrects the tab markup on the comment review page. These
tabs are just links styled as tabs -- there isn't any JS tab swapping.
This kind of "static" tab markup wasn't handled by the tabs WRAPPER
work.
To test you should have some comments data in your system:
- Go to Administration -> System preferences and enable the
"OPACComments" preference.
- Log in to the OPAC and search for a bibliographic record.
- View the detail page for the record and click the "Comments" tab.
- Click "Post your comments on this title."
- Enter some text in the review box and submit.
In the staff interface, go to Tools -> Comments.
- You should see two tabs: "Approved comments" and "Comments awaiting
moderation."
- Confirm that the tabs look correct.
- Approve one or more comments and confirm that the tabs work correctly
to switch views.
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When placing a hold on multiple biblios Place Holds page (request.pl) has checkboxes for unselecting some of the listed biblios.
Removing the checkmark does not actually unselect the biblio. Clicking the Place holds button will place a hold for all the biblios on page that can be reserved.
If unchecked biblio does not have a pickup location, it will get past form validation and cause an error.
Test plan:
1. Select several biblios and choose Place hold
2. Choose a patron
3. Select a pickup location for all biblios and unselect one of the checkmarks
4. Place holds and note that even the deselected holds was placed.
5. Repeat steps 1-2.
6. Leave pickup locations empty and try to place the holds.
7. Note alert: "Please make sure all selected titles have a pickup location set"
8. Uncheck one of the biblios and add pickup locations to the checked biblios.
9. Try to place the holds and note that there is no alert, and you get an error 500.
10. Apply patch.
11. Repeat steps 1,2,8 and place holds.
12. Note that there is no error 500, and while all the biblios are shown on page, only the checked biblios have a new hold placed on them.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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 systempreferences are the button to cancel deleting a local
preference, which can be fixed with no visible change, and the button to
return to the preferences list after being told that your requested deletion
has been done, which makes a visible change because right now, the whole page
that tells you the preference was deleted doesn't show at all.
Test plan:
1. Without the patch, Administration - System preferences - Local use (in the
left sidebar)
2. New system preference - Explanation and Variable are required, so make
them both Trash and Save
3. In the row for your new preference, click the Delete button
4. In the confirmation page, click the No, do not delete button
5. You'll be taken back to the list of Local use preferences. That's the
behavior that you want to see unchanged after the patch
6. Click the Delete button for your preference again, but this time click
Yes, delete
7. You'll be taken to a blank page with no category of preferences selected
or listed. That's the behavior that you want to see change with the patch
8. Apply patch, restart_all
9. Administration - System preferences - Local use - New system preference -
'Trash' for both Explanation and Variable - Save
10. In the row for the new preference, click the Delete button
11. In the confirmation page, click No, do not delete
12. Verify that it returns you to the list of Local use preferences just like
before
13. Click Delete again, but this time click Yes, delete
14. Now you should get a page saying "Data deleted" with a Back to system
preferences button. Click that button, you should return to the list
of Local use preferences, with your Trash preference gone
Sponsored-by: Chetco Community Public Library
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Julian Maurice <julian.maurice@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If table aqbudgets is miissing foreign key
'aqbudgetperiods_ibfk_1' database update fails on
"Can't DROP FOREIGN KEY" error.
To test:
1. Remove changes made in bug 32132, drop foreign key
aqbudgetperiods_ibfk_1 and downgrade your database:
- ALTER TABLE aqbudgets MODIFY COLUMN `budget_period_id` INT(11) NULL;
- UPDATE aqbudgets SET budget_period_id = NULL
WHERE budget_period_id IN(SELECT budget_period_id FROM aqbudgetperiods
WHERE budget_period_description = "Budget for funds without budget");
- DELETE FROM aqbudgetperiods
WHERE budget_period_description = "Budget for funds without budget";
- ALTER TABLE aqbudgets DROP FOREIGN KEY aqbudgetperiods_ibfk_1;
- UPDATE systempreferences SET value="23.1200022" WHERE variable = "Version;
2. Upgrade your database (e.g. running installer/data/mysql/updatedatabase.pl)
=> Update fails on error "Can't DROP FOREIGN KEY `aqbudgetperiods_ibfk_1`;...".
4. Apply this patch.
5. Try to update your database again.
=> Database should now be upgraded succesfully.
=> Confirm table aqbudgets now contains 'aqbudgetperiods_ibfk_1'.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch corrects instances of the double-underscore function being
used in .tt files where the single-underscore function should
be used instead.
To test, apply the patch and update a translation, e.g. fr-FR:
> gulp po:update --lang fr-FR
- Open the corresponding .po file for the affected strings, in this
case misc/translator/po/fr-FR-staff-prog.po
- Confirm that the strings are now in the .po file for translation. You
should find these lines:
- koha-tmpl/intranet-tmpl/prog/en/modules/members/alert-subscriptions.tt:
"Are you sure you want to unsubscribe %s from email alerts for %s?"
- koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
"Click to expand this section"
- Check fr-FR-opac-bootstrap.po for this line:
- koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-alert-subscriptions.tt:
"Are you sure you want to unsubscribe %s from email alerts for %s?"
Sponsored-by: Athens County Public Libraries
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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 reserve/request.tt the modal for cancelling a hold looks like it is a form
that will do a POST without an op input, but in fact it requires JavaScript to
work at all, and with JavaScript it clears out the div where it stashes inputs
and then inserts one with the op cud-cancel.
To persuade the test at xt/find-missing-op-in-forms.t that there is an op,
and to let a casual skimmer of the code see what that op will be, without
actually changing the behavior in any way, we can just stick the op in the
div which the JS will .empty() out before sticking the same thing back in.
Test plan:
1. Search for any record with an item, click Place hold, place two holds
2. In the row for the second hold, click the trash can icon to delete
3. Nothing changed from normallly cancelling a hold, did it? It shouldn't
have.
Sponsored-by: Chetco Community Public Library
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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.
For itemtype administration, that's the "No, do not delete" cancel button
when you decide not to delete an itemtype, which doesn't need to POST
anything since it's just taking you back to the list of itemtypes. The only
visible change from switching to a GET is that the URL ends with a "?" from
a GET with no params, but someone can fix that by choosing one of our various
link-as-a-cancel-button styles and switching it to a link in a bug that
doesn't block an RM_priority bug.
Test plan:
1. You aren't going to see a visible difference, so start with the patch
applied
2. Administration - Item types
3. You need an itemtype that isn't in use to be able to delete it - ktd
provides you with an unused Computer Files type, so click the Delete
button for that row
4. In the "Are you sure..." page, click No, do not delete
5. Verify that you are back at the list of itemtypes, with only the "?" at
the end of the URL to tell you that you did a GET rather than a POST
Sponsored-by: Chetco Community Public Library
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds the missing "dropdown-item" class to the link in the
header menu for the preservation module.
To test, apply the patch and enable the preservation module
(PreservationModule).
Reload the page and click "More" in the header menu. The "Preservation"
link should be styled like all the others.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
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 MARC bibliographic frameworks, that's the tag search form, which
should be a GET so the URL includes what you searched for and you can
bookmark it or link to the search, and the cancel "No, do not delete"
button in the page to confirm deleting a subfield, which should also be
a GET to take you back to the page where you were, which was
?tagfield=903&frameworkcode=VR when you clicked Delete.
Test plan:
1. No visible change in behavior (only the URL), so start with the
patch applied
2. Administration - MARC bibliographic framework - choose one other
than Default, since the "&framework=" of Default could be confused
with a failure to get the code in there - Actions - MARC structure
3. Type any three digit number higher than 009 (you want something with
subfields) in the Search for tag input and hit Enter
4. Verify that your URL has the searchfield and frameworkcode correct
and that number or next highest number tag is displayed first
5. Change the In framework select menu to another non-Default framework
and click search, and verify that the URL change to that
frameworkcode, and that framework is displayed
6. Toggle the Display only used tags/subfields checkbox, search for a
different tag, and verify that the state of the checkbox persists as
you do more searches
7. On any other listed tag - Actions - View subfields
8. For any displayed subfield click Delete
9. In the confirmation page click No, do not delete
10. Verify that the page you return to has the correct tagfield and
frameworkcode for the tag you chose
Sponsored-by: Chetco Community Public Library
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There are several things going on here.
The tests are failing randomly when some additional class sources are in the
DB. This should never happen on Jenkins, but it happened, see the third
patch of this patch set (spoiler: tests not run within a txn)
There were also a sorting problem: by default sort will show
uppercases first:
A, B, C, a, b, c
However we want:
a, A, b, B, c, C
which is what fc does (https://perldoc.perl.org/functions/fc)
Test plan:
0. Checkout the main branch, without patches from this patchset.
1. Run t/db_dependent/ClassSources.t several times
=> Notice that new entries in the DB table 'class_sources' are created
2. Run t/db_dependent/Koha/UI/Form/Builder/Biblio.t and
t/db_dependent/Koha/UI/Form/Builder/Item.t
=> They fail (if not, run t/db_dependent/ClassSources.t again)
3. Apply the patches
4. Run t/db_dependent/ClassSources.t
=> No more additional entries in DB, tests are correctly run within
transactions
5. Run t/db_dependent/Koha/UI/Form/Builder/Biblio.t and
t/db_dependent/Koha/UI/Form/Builder/Item.t several times
=> They always pass
Note that the sort should actually be done on the description, not the
code. But that's for another bug...
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Not directly related to the failure, only a bit of cleaning before
starting.
Signed-off-by: CJ Lynce <cj.lynce@westlakelibrary.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The audio alert feature is not correctly designed and is problematic.
It looks at the class name in the DOM, not when the element with this class name
will be displayed to the end user
So it's not possible to make it work for modals for instance, or if an element
is built in JS then displayed
This patch remove the modal code from the code, if there are no waiting
holds. It is the behaviour that existed prior to the Bootstrap update.
However it is kind of random behaviour, the song that is played when the
librarian open the circ page is different if the user has waiting holds or not.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Follow Joubu's test plan. It should no longer fail.
Error from eval Koha::CirculationRules->set_rules($params) at onboarding.pl was:
set_rule cannot set 'bookings_trail_period' for a 'categorycode'! at /kohadevbox/koha/installer/onboarding.pl line 301.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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 Holds to pull that's the form which lets you change from the default
starting and ending date. Switching that to a GET at least lets you refresh
the page without getting a browser warning about resending a POST and maybe
having your credit card double-charged.
Test plan:
1. Without the patch, Circulation - Holds to pull - change the start date to
something earlier and click Submit
2. Refresh the page, get a warning about resubmitting data
3. Apply patch, Circulation - Holds to pull - change the start date to
something earlier and click Submit
4. Refresh the page, no warning
Sponsored-by: Chetco Community Public Library
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Found using `egrep 'class=[^>]+class=' **/*.tt **/*.inc`
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
