This patch updates the three scripts that fetched the soonest renewal date
to use the return from CanBookBeRenewed
To test:
1 - Set a circulation rule with a 'no renewal before' set to 3, loan length set to 5
2 - Check out an item to a patron that uses this rule
3 - Verify the checkouts for the patron show the correct 'No renewal before' date
4 - Sign in to the patron's opac account
5 - Verify the item shows it cannot be renewed, and shows the correct date
6 - Go to Circulation->Renew
7 - Attempt to renew using barcode
8 - Confirm error shows the soonest renewal date
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We got
Can't call method "value" on unblessed reference at /kohadevbox/koha/opac/opac-messaging.pl line 86
$cookie can be an arrayref, we should retrieve the session id using
CGI->cookie('CGISESSID')
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch replaces the AutoEmailOpacUser system preference with a new
AutoEmailNewUser preference. This makes the functionof the preference
clearer.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch updates all references to the former ACCTDETAILS notice to
use the new WELCOME email notice instead.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The error pages wrote a HTTP status code of 200 for all PSGI requests, even
though it should have only done it for PSGI requests from the ErrorDocument
middleware. This patch fixes that.
0) Do not apply patch
1) Open F12 dev tools and go to Network tab
2) Go to http://localhost:8081/files/blah
3) Note that the webpage is a 404 error but HTTP status code is 200
4) Go to http://localhost:8081/cgi-bin/koha/circ/blah
5) Note that the webpage is a 404 error and HTTP status code is 404
6) Apply patch
7) Go to http://localhost:8081/files/blah
8) Note that the webpage is a 404 error and HTTP status code is 404
9) Go to http://localhost:8081/cgi-bin/koha/circ/blah
10) Note that the webpage is a 404 error and HTTP status code is 404
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch modifies the way Koha sets cookies so that the "sameSite"
attribute is explicitly set to "Lax." This option is chosen because it
is the value which is currently assumed by browsers when the sameSite
attribute is not set.
To test, apply the patch and restart services.
- Log in to the staff interface and open your browser's developer tools.
- In Firefox, look for a "Storage" tab.
- In Chrome, look for an "Application" tab.
- Under "Cookies," click the URL of the staff interface.
- You should see all the cookies which are set for that domain.
- The CGISESSID cookie should have sameSite set to "Lax."
- Go to Cataloging -> New record.
- Check the "marcdocs" and "marctags" cookies.
- Switch to the Advanced MARC editor (you may need to enable
theEnableAdvancedCatalogingEditor preference).
- Check the "catalogue_editor" cookie.
- Add a new item to an existing bibliographic record.
- Check the "LastCreatedItem" cookie which is set after you save the
new item.
- Go to Authorities -> Authority search.
- In authority search results, click "Merge" from the "Actions" menu
next to one of the results..
- Check the "auth_to_merge" cookie.
- Go to Administration -> MARC bibliographic framework
- Choose "MARC structure" from the menu corresponding to one of the
frameworks.
- Check the "Display only used tags/subfields" checkbox.
- Check the "marctagstructure_selectdisplay" cookie.
- Go to Circulation -> Check out to a patron with checkouts.
- Check the "Always show checkouts immediately" checkbox.
- Check the "issues-table-load-immediately-circulation" cookie.
- Go to Tools -> Patron clubs. You will need at least one active club
with one or more patrons enrolled.
- From the list of clubs, click Actions -> Search to hold.
- Check the "holdforclub" cookie.
- Go to Tools -> Batch item modification and submit a batch of items.
- Uncheck one or more checkboxes in the "Show/hide columns" area.
- Check the "showColumns" cookie.
- View a patron -> Search to hold.
- Check the 'holdfor' cookie.
- With WebBasedSelfCheck enabled, log in to the self-checkout page.
- Check the "JWT" cookie.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
If a staff member has access to the staff client (either because
'catalogue' permission is enabled or they're a superlibrarian
then that user can add items (from OPAC or staff client) to a list
marked 'Staff only'
Test plan:
1. In the staff client go to: Lists > 'New list'. Notice under 'Allow changes to contents
from' there are three options: Nobody, Owner only, Anyone seeing this
list
2. Apply first 3 patches and run updatedatabase.pl
cd installer/data/mysql
sudo koha-shell <instance>
./updatedatabase.pl
3. Restart memcached and plack
4. Create 4 patron accounts:
- User A : Superlibrarian permissions
- User B : 'Staff access, allows viewing of catalogue in staff interface
(catalogue)'
- User C : No permissions
- User D : 'Staff access, allows viewing of catalogue in staff
interface' and 'Lists' > Edit public lists (edit_public_lists)' sub-permission
5. Login to staff client as User A.
Create a public list and select the new 'Staff only' option under 'Allow changes to contents from'
6. Log into the staff client as User B.
Confirm you can add items to the list from the following staff client pages:
- Individual list page using the 'Add items' button
- Staff client search result page
- Staff client biblio detail page
7. Confirm you can remove items from the list
8. Confirm you can perform an OPAC search when not logged in
9. Log into the OPAC as User B. Confirm you can add items to the list
from the following OPAC pages:
- OPAC search result page
- OPAC biblio detail page
10. Log into the OPAC as User C. Do an OPAC search and confirm you
can view the list, but not add items to it
11. Login to the staff client as User B. Create a new list with the
following settings:
- 'Category'='Private',
- 'Allow changes to contents from'='Staff only'
Notice a red hint message is displayed.
Change 'Category'='Public' and notice the hint is removed
12. Log into the OPAC as User C. Notice the 'Staff only' option is not
available when creating a list
13. Log into the OPAC as User B. Repeat step 11. Confirm the same
outcome
14. Log into the staff client as User A. Create a list with the
following settings:
- Public = 'Public'
- Allow changes to contents from = 'owner only'
15. Log into the staff client as User D. Edit the list from step 14
confirm you can edit the list to have 'Allow changes to contents from' =
'Staff only'
16. Run Patron.t and Virtualshelves.t unit tests:
sudo koha-shell <instance>
prove t/db_dependent/Koha/Patron.t
prove t/db_dependent/Virtualshelves.t
Sponsored-by: Horowhenua District Council, New Zealand
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a new system preference, OpacAdvancedSearchTypes, as an
OPAC-specific version of the AdvancedSearchTypes preference. Values from
AdvancedSearchTypes are copied to OpacAdvancedSearchTypes so that
behavior is consistent.
The patch also alters the output of the "Most popular" page so that:
1. The page heading is correct ("Most popular titles" instead of "Top
issues").
2. The table show both item type and collection whether or not the user
has submitted query with one of those fields as a filter.
To test, apply the patch and run the database update process.
- Go to Administration -> System preferences.
- Search for AdvancedSearchTypes. You should get two results, one for
the OPAC preference and one for the staff interface.
- Check that the OpacAdvancedSearchTypes settings match the
AdvancedSearchTypes settings.
- View the advanced search pages in the staff interface and OPAC to
confirm that the tabs look correct.
- Change the OpacAdvancedSearchTypes and AdvancedSearchTypes settings to
be different and confirm that each is applied separately to each
interface.
- Enable the OpacTopissue system preference.
- View the "Most popular" page in the OPAC.
- The page heading should be correct.
- The OpacAdvancedSearchTypes settings should be reflected in the
"Refine your search" sidebar: If "Collection" is checked, a filter
for collection should appear. If "Item types" is checked, a filter
for item types should appear.
- The output of your search should include collection and item type
regardless of what filters you've submitted.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Some discovery tools can't translate ISL-DI results, it would be useful
if we can get ISL-DI output already translate.
This patch add an optional parameter language to GetAvailability, and
make GetAvailability results translatable.
If no parameter is given the output language is the language of the
cookies is present or the first language in the opac language list.
Test plan:
1. Enable the ILS-DI system preference
2. Locate a record
3. Test these URLs:
[OPACBASEURL]/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id=[BIBLIONUMBER]&id_type=biblio
and
[OPACBASEURL]/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id=[ITEMNUMBER]&id_type=item
(Where the [OPACBASEURL] is the OPAC URL of your test instance,
[BIBLIONUMBER] and [ITEMNUMBER] are a record number and item number of
your choice.)
4. Apply the patch
5. Test these URLs:
[OPACBASEURL]/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id=[BIBLIONUMBER]&id_type=biblio&language=[LANGUAGE]
and
[OPACBASEURL]/cgi-bin/koha/ilsdi.pl?service=GetAvailability&id=[ITEMNUMBER]&id_type=item&language=[LANGUAGE]
(Where the [OPACBASEURL] is the OPAC URL of your test instance,
[BIBLIONUMBER] and [ITEMNUMBER] are a record number and item number of
your choice, [LANGUAGE] is a language code ex: 'en' or 'fr-FR')
6. The results should now be in the requested langugage
Sponsored-by: University Lyon 3
Signed-off-by: Sonia <sonia.bouis@univ-lyon3.fr>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
There are 2 prefs that control the default view of biblio detail pages:
IntranetBiblioDefaultView for staff and BiblioDefaultView for OPAC.
There are as well viewISBD, viewLabeledMARC and viewMARC to allow/don't
allow access to those page for staff members.
This code need to be in a single place to avoid discrepancy.
Test plan:
Play with BiblioDefaultView and IntranetBiblioDefaultView and confirm
that the links of biblio point to the correct view.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The self registration form stores a new borrower as a borrower modification when verifying by email.
Borrower modifications can handle extended attributes.
This patch simply sotres the extended attributes in the modifications table, and approves a modification
to the extended attributes only after patron is created
To test:
1 - Apply patch
2 - Create a patron attribute and set it as viewable/editable in the OPAC
3 - Set system preference PatronSelfRegistrationVerifyByEmail
4 - Reigster a new patron on the OPAC, provide an email and populate the extended attribute
5 - Retrieve the verification token, the last on in the messages table
SELECT * FROM message_queue;
6 - Go tot he url from above
7 - Confirm successful patron creation
8 - View patron record and confirm attribute was set
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This alters the svc scripts to set the report id after fetchign the report object
to ensure it is passed to exectue query
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The last run of a report is updated only if method execute_query() is
called with report_id.
This whas missing for :
- when report is run publicly
- when report is sent by email
- when report is exported
Patch changes the method signature to use a hash of params, in order to
easily avoid some params.
Test plan :
1) Create a report.
2) Run report.
3) Check the report listing. Confirm that the last run info on the report is updated.
4) Make report public.
5) Run report via public url.
6) Check the report listing. Confirm that the last run info on the report IS NOT updated.
7) Schedule the report to run at a given time and e-mailed to an address.
8) After the report runs at the scheduled time, check the report listing. Confirm that the last run info on the report IS NOT updated.
9) Run report.
10) Export results.
11) Check the report listing. Confirm that the last run info on the report IS NOT updated AT THE TIME OF THE EXPORT.
Questionable (I don't know if this is addressed):
12) Run report on backend through a cron job and send results via e-mail.
13) Check the report listing. Confirm that the last run info on the report IS NOT updated.
14) Apply patch.
15) Rerun steps 2-13. Confirm that steps 3, 6, 8, 11, and 13 DO UPDATE the last run info.
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Séverine Queune <severine.queune@bulac.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Trivial fix.
Test plan:
Delete two lines from opac search history.
Verify results. Check plack-opac-error.log.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This is a follow-up patch for bug 29543. If an invalid cardnumber has
been used we should not generate a token.
Test Plan:
1. Set SelfCheckoutByLogin to 'cardnumber'.
2. Go to http://localhost:8080/cgi-bin/koha/sco/sco-main.pl
3. Enter an invalid carnumber like 'thisisabadcardnumber'
4. See the appropriate message "Sorry The userid thisisabadcardnumber was not found in the database. Please try again."
5. Try again with a different cardnumber and notice the same exact error message including the 'thisisabadcardnumber' cardnumber.
6. Apply this patch
7. Restart all the things!
8. Repeat steps 2-4
9. Try again with a different cardnumber, you should now see the correct
cardnumber!
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds the ACCTDETAILS notice trigger to the opac self
registration process. Allowing new users, with varification enabled,
to receive the ACCTDETAILS notice immediately after their account is
varified.
Test plan
1) Enable AutoEmailOpacUser system preference
2) Ensure the ACCTDETAILS notice is configured
3) Ensure `PatronSelfRegistrationVerifyByEmail` is enabled
4) Register a new user via the opac self registration process using an
email address you have access to
5) Verify the user by following the link in the verification email you
should have received.
6) The new user should have been created and you should be able to see
the account details notice in their associated notices
7) Confirm that the email address used above has received the notice.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds the ACCTDETAILS notice trigger to the opac self
registration process. Allowing new users, without varification enabled,
to receive the ACCTDETAILS notice immediately after their account is
created.
Test plan
1) Enable AutoEmailOpacUser system preference
2) Ensure the ACCTDETAILS notice is configured
3) Ensure `PatronSelfRegistrationVerifyByEmail` is disabled
4) Register a new user via the opac self registration process using an
email address you have access to
5) The new user should have been created and you should be able to see
the account details notice in their associated notices
6) Confirm that the email address used above has received the notice.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Although less harmful indeed. No borrowernumber, no image.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tested: logged in, logged out, prefs toggled. All fine.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
When system preference is off, call no code related to Koha::Recalls.
Also add some missing module import.
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the different ->recalls accessors implemented on this
bug be more standard. This means:
- They don't do special things like default sorting or stripping out
special parameters. That's all left to the caller and the methods are
clean: they just return the related objects
- Useful filtering methods for Koha::Recalls resultsets are added. The
only used one (in the end) was ->filter_by_current. It seems like a
better approach, because it gives devs more control on how they want
to chain things, and there's a single place in which to maintain the
criteria of what is 'current' or 'finished'. This clearly makes the
'old' column obsolete IMHO, at least in the use cases I found. This is
covered by tests as well.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Due to the wantarray change, we should fix this call in list context.
We should either use an iterator now or append as_list.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
And making reverted ajax message clearer
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
- removing authnotrequired flag from scripts
- fixing opac buttons
- chmod +x for recalls test files
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
- place a biblio-level or item-level recall via the biblio detail page, OPAC search results, or course reserves
- view or cancel your active recalls from 'your summary' recalls tab
- view all active and inactive (and cancel active) recalls from 'your recall history'
- stopped from placing a reserve on an item that the patron has already recalled
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On the ktd sample database when trying to go to the detail page from the result list:
Undefined subroutine &CGI::Compile::ROOT::kohadevbox_koha_opac_opac_2ddetail_2epl::searchResults called at /kohadevbox/koha/opac/opac-detail.pl line 260
Turning off OpacBrowseResults makes the error disappear.
In opac-detail.pl, use C4::Search is missing searchResults and getRecords
To test:
- Search for something that gives several result pages in OPAC, example: e
- Switch to one of the last pages using link on top of results, example: 10
- Open any of the records listed in detail view
- Verify that the error is shown
- Apply patch and repeat, error is gone and browsing behaves as expected
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The method Koha::AuthorisedValues->authorised_value is not covered by tests!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch adds a 'holdable' and 'unholdable' class to the rows of the table
Additionally I rename the 'backgroundcolor' field to 'onloan' as that is what it contains.
Note: Out of the box, there is no css associated with this class
I add a div around the table to allow hiding the new buttons as well when optiuons are hidden
It would be nice in the future to utilise a Koha table here, however, it is complicated by multi-holds
To test:
1 - Add a number of items to a record, ensuring they belong to different libraries
2 - Set 'Default checkout, hold and return policy'->'Hold policy' to 'From home library'
3 - Sign in to opac and attempt to placehold on the record
4 - Click 'show more options' and 'a specificitem'
5 - Note holds table includes items that cannot be held
6 - Apply patch
7 - Reload holds page
8 - Note items that cannot be heldare hidden
9 - Click 'Show unholdable items' and note they appear
10 - Click 'Hide unholdable items' and veriofy they hide
11 - Test with multi holds
Signed-off-by: The Minh Luong <the-minh.luong@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Bug 29844 forgot to add as_list to opac-search.pl.
You can see it changed search.pl
Patch fixes and also adds explicit interface = opac in get_search_groups() call.
Since intranet is explicit, opac should also be.
We keep opac as default value.
Test plan :
1) Create a libary group for OPAC and one for staff
2) Go to OPAC advanced search page
3) Check you see the OPAC libary group
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
This patch makes the opac/opac-privacy.pl OPAC page use the new
anonymize method.
To test:
1. Have some checked-in materiales
2. Have OPACPrivacy enabled
3. Notice your checkouts history contains what you expect
4. Go to 'your privacy'
5. Click on 'Delete checkout history'
=> SUCCESS: It works, no crash.
6. Sign off :-D
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The same way we have a button to immediately delete the checkouts history in the OPAC, we should have a similar option for the holds history.
This patch implements that.
To test:
1. Have a patron with some old checkouts and old holds.
2. Have OPACPrivacy, OPACHoldsHistory and opacreadinghistory enabled.
3. Notice in the OPAC the patron has some old checkouts and holds.
4. Use the Privacy tab to clean checkouts
=> SUCCESS: They are still cleaned as before this patch
5. Try to clean the old holds
=> SUCCESS: They are cleaned!
6. Add some old checkouts and holds
7. Use the new 'All' button
=> SUCCESS: All cleaned
8. Sign off :-D
Signed-off-by: Barbara Johnson <barbara.johnson@bedfordtx.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Test plan:
Logout in OPAC.
Goto sco help page.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Certainly since bug 29543 and bug 29914.
We should do the same authentication check than sco-main.pl, and also
make sure to generate the checkout history only for the logged in patron
(the OPAC one, not staff member)
Test plan:
Use the different combinations of the SCO config (AutoSelfCheckAllowed,
SelfCheckoutByLogin and WebBasedSelfCheck) and confirm that this patch
fixes the SCO print slip feature.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 29844 we decided to remove wantarray from Koha::Objects->search.
Reviewing the difference occurrences I found some unnecessary uses of ->as_list,
where iterators should be used instead.
This patch only removes the obvious places, not the tricky ones.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
and some more...
There are lot of inconsistencies in our ->search calls. We could
simplify some of them, but not in this patch. Here we want to prevent
regressions as much as possible and so don't add unecessary changes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
I think this is a better approach for the same thing. Posting it just in
case it helps.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
We must check if logged in user is trying to modify one of their
checkouts
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Checkin or renew must be restricted to the items they own.
Test plan:
Create an item with barcode bc_1
Check it in to user A
Login to SCO with user B
Get the token using the browser dev tool, from the cookie
Hit (replace $JWT)
/cgi-bin/koha/sco/sco-main.pl?jwt=$JWT&op=renew&barcode=bc_1
/cgi-bin/koha/sco/sco-main.pl?jwt=$JWT&op=returnbook&barcode=bc_1
You should see an error message
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
The self-checkout feature is assuming a patron is logged in if patronid
is passed. It also assumes that "We're in a controlled environment; we
trust the user", which is terribly wrong!
This patch is suggesting to generate a JSON Web Token (JWT) to store in
a cookie and only allow action (renew, check in/out) is the token is
valid. The token is only generated once the user has been authenticated
And is removed when the user finish the session/logout.
Test plan:
You must know exactly how the self-checkout feature works to test this patch.
The 4 following sysprefs must be tested:
SelfCheckoutByLogin, AutoSelfCheckAllowed, AutoSelfCheckID, AutoSelfCheckPass
Confirm that you can renew, checkin for the items you own, and checkout new items.
Confirm that you are not allowed to access other account's info.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
