This reverts commit c7fef23763.
The code is needed back to fix broken sorting.
Signed-off-by: Christian Nelson <christian.nelson@tritonia.fi>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Deleting a patron or patron club causes server error on searching.
To recreate:
- create a club template
- create a club
- enroll a patron in the club
- from the clubs page, select Search To Hold for your club
- do a search, see that it says "Hold for [club name]" in your search results page
- go back to the clubs page and delete your club
- try to perform a search
=> Without this patch you get "Can't call method "name" on an undefined value at /kohadevbox/koha/catalogue/search.pl line 207"
Same when placing a hold for a patron (check the search result and the
detail pages)
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha plugins hook 'intranet_catalog_biblio_tab' is for a template,
it will be better it uses Template Toolkit plugin like intranet_js, ...
It will allow using it in other places like MARC details page for example.
Test plan uses a plugin from git.biblibre.com because this hook is not
yet in KitchenSink.
Test plan :
1) Enable Koha plugins
2) Download and install the latest version of this plugin
https://git.biblibre.com/biblibre/koha-plugin-intranet-detail-hook
3) Browse to catalogue/detail.pl for a record
4) Note you see two new tabs with content
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves C4::Biblio::GetMarcNotes to
Koha::Biblio->get_marc_notes. This is so get_marc_notes can be
used in templates and notices.
To test:
1. Find a record that has a note (3xx for UNIMARC, 5xx for MARC21).
Confirm the notes still show as normal under the Descriptions tab.
2. Add the record to the cart.
3. View your cart and click 'more details'. Confirm notes show as
normal.
4. Log in to the OPAC. Find the record and add it to the cart
5. View the cart and click 'more details'. Confirm notes show as
normal.
6. View the record detail page and confirm the notes show as normal
under the Title Notes tab.
7. Confirm tests pass:
- t/Biblio.t
- t/db_dependent/Koha/Biblio.t
Sponsored-by: Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch modifies the toolbar shown on bibliographic detail pages so
that the "Add to cart" and "Add to lists" buttons are separate. The "Add
to cart" will now reflect whether the title is in the cart. The "Add to
lists" button will now be a menu of list choices like it is on the
search results page.
To test, apply the patch and rebuild the staff client CSS
(https://wiki.koha-community.org/wiki/Working_with_SCSS_in_the_OPAC_and_staff_client).
Search for a title in the staff client and view the detail page for one
of the results.
Testing the cart button:
- In the toolbar you should see an "Add to cart" button and an "Add to
lists" menu button.
- Clicking the "Add to cart" button should show the cart message
associated with cart link in the header.
- The label showing the number of items in the cart should be
incremented.
- The button should change to a "Remove from cart" button.
- Clicking the "Remove from cart" button should correctly remove the
item from the cart:
- The label showing the number of items in the cart should be
decremented.
- The button should change to "Add to cart."
- Add a title to the cart and click the cart link in the header to open
the cart pop-up window.
- Click the "Empty and close" button in the cart window.
- After you confirm the cart window should close. The "Remove from
cart" button should now be an "Add to cart" button.
- Add a title to the cart and navigate between each of the other views
of that title: Normal, MARC, Labeled MARC, and ISBD. On each page you
should see a "Remove from cart" button.
- Test the add and remove functions from each of the other bibliographic
detail views.
Testing the lists button:
- On the normal bibliographic detail page you should see an "Add to
list" menu button. Clicking it should reveal the same kind of lists
menu you see on the catalog search results page, with recent public
and private lists and options for "More lists" and "New list."
- Test that each of these options works correctly to trigger the
expected pop-up window.
- Confrim that the correct title is added to the correct list.
- Perform this test from each of the bibliographic detail pages: Normal,
MARC, Labeled MARC, and ISBD.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
In this patch we remove the limitation of 1 cover image per item
Sponsored-by: Gerhard Sondermann Dialog e.K. (presseplus.de, presseshop.at, presseshop.ch)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset adds the ability to attach cover images at item level.
This commit message will explain the different patches that are
following.
The main idea is to have cover images for a given item. This is useful
for a bibliographic record linked with a subscription. Each item could
have the cover image for the serial numbers.
In this first patch there is a limitation to allow only 1 cover per
item, but a later patch will remove it. That way we will take advantage
of the recent work done to display nicely cover images (bug 25031), and
reuse it in this development (staff interface only).
In order to use a flexible and robust code, the legacy C4 code
(C4::Images) has been moved to Koha::CoverImages. Also the DB table
biblioimages has been renamed cover_images.
Test plan (for the whole patch set):
0. Turn off AllowMultipleCovers
1. Create a new bibliographic record and items
2. Attach a cover image to the bibliographic record
3. In the item list of the bibliographic detail page, you will notice a
new "Upload image" action. Select it
4. Select an image
=> Notice the new column in the item table
5. Upload another image
=> You cannot upload 2 images, you are going to replace the existing one
6. Turn on AllowMultipleCovers
7. Attach another image to the image
=> Notice the 2 images are displayed nicely, with navigation controls
8. Confirm you can view an image if you click on it and you can delete it
9. Test the OPAC view now
=> Cover image for items are displayed in the table, there is no
navigation controls here however.
Sponsored-by: Gerhard Sondermann Dialog e.K. (presseplus.de, presseshop.at, presseshop.ch)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch replicates the introduced behaviour, for the admin interface.
To test, follow the test plan from the OPAC, but on the intranet.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
It defaults to 0 in get_template_and_user
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is a "norequest" boolean passed to the include cat-toolbar.inc, to
display or not the "Pace hold" button.
This flag was not calculated in some place (ISBDdetail and moredetail
for instance)
Here we centralize the code to make it more robust and less regression
prone.
Note that the same problem appears at the OPAC (opac-MARCdetail is
always display the button). That will have to be fixed separately
Test plan:
Create biblio A with 0 item, B and C with 1 item and D with 2 items
item for B is not for loan, C is for loan and D has 1 of each
Go to the bibliographic detail page of each record and confirm that the
"Place hold" button appears appropriately.
Test the different tabs of the catalogue module
QA note: This patch is only centralizing the existing code, but it is
still too naive. To manage the visibility of this button we certainly
want to copy what is done in C4::Search::searchResults:
# can place a hold on a item if
# not lost nor withdrawn
# not damaged unless AllowHoldsOnDamagedItems is true
# item is either for loan or on order (notforloan < 0)
$can_place_holds = 1
if (
!$item->{itemlost}
&& !$item->{withdrawn}
&& ( !$item->{damaged} || C4::Context->preference('AllowHoldsOnDamagedItems') )
&& ( !$item->{notforloan} || $item->{notforloan} < 0 )
);
Signed-off-by: Didier Gautheron <didier.gautheron@biblibre.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is never used.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This is never used.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Joonas Kylmälä <joonas.kylmala@helsinki.fi>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patchset adds a new syspref: BiblioItemtypeInfo
If you set BiblioItemtypeInfo to Koha, you will see the Koha
record level itemtype info. This info is also shown if item-level_itypes
is set to biblio
Display of icons are controlled by
noItemTypeImages/OpacnoItemTypeImages
Material type display is controlled by DisplayIconsXSLT/DisplayOPACIconsXSLT
To test:
1 - Apply patch
2 - Update database
3 - Do an opac search and view results
4 - Switch pref to 'Koha' and refresh
5 - Note itemtypes appear
6 - Click in to a record details
7 - Note you see itemtype and icon
8 - Switch the pref
9 - Note you don't see record level itemtype and icon
10 - Repeat in staff interface
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There are several calls in catalogue/detail.pl that can be removed:
GetMarcISBN, GetMarcAuthors, GetMarcSubjects, GetMarcSeries, GetMarcUrls and GetMarcHosts
They pass a variable to the template that is never used.
Test plan:
Confirm that this TT variable is never used.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch moves the syspref check into the controller to save a DB
query if the module is not enabled.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
JD - amended patch: removing trailing parenthesis in the IF statement
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Some ILL systems (e.g. Libris in Sweden) require a link between
a biblio and an ILL request. When such a link exists it is nice
to display an actual link from the biblio detail view to the
ILL request detail view. This patch adds such a link. For users
without ILL privileges, the requests should still show, but not
be clickable links.
To test:
- Make sure you have a couple of ILL requests created with the
FreeForm backend. (FreeForm does not let you tie a request to
a biblio through the UI, but we will add connections directly
in the database.) Lets assume these have illrequest_id's a and b.
- Make sure you have a record, let's call the biblionumber x.
- Apply the patch and make sure there are no changes in the biblio
detail view of biblionumber x.
- Log into the database and connect the biblio to the first request:
UPDATE illrequests SET biblio_id = x where illrequest_id = a;
- Check that the biblio detail view now says this:
"ILL requests: Request a"
- Verify that the "Request a" part is a working link to the detail
view of ILL request a.
- Do this in the database:
UPDATE illrequests SET biblio_id = x where illrequest_id = b;
- Check that the biblio detail view now says this:
"ILL requests: Request a, Request b"
- Verify the links work as expected.
- Log in as a staff user and check that the requests are still
listed, but not displayed as clickable links.
- Sign off
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
However we are adding a note on top of the table to tell how many
suggestions are archived. It seems that there is no good reason to
display the archived suggestions on this table.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a new "Suggestion detail" tab on the bibliographic
detail page. It will help suggestion management.
Test plan:
- Create several suggestions for a given biblio
- Go to the detail page of the bibliographic record and confirm that
there is a new "Suggestion detail" tab with all the suggestions you
created.
Signed-off-by: Séverine QUEUNE <severine.queune@bulac.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Owen Leonard 2018-03-16 10:47:47 UTC :
<<
I don't think the system preference adds any security. There are already multiple permissions required for working with plugins:
- Configure plugins
- Manage plugins ( install / uninstall )
- Use report plugins
- Use tool plugins
And even with those permissions your server must be configured to allow the use of plugins.
>>
Test plan :
1) Install kitchen sink plugin https://github.com/bywatersolutions/koha-plugin-kitchen-sink
2) Run misc/devel/install_plugins.pl
3) Set config enable_plugins=1
4) Check all parts of the plugin are working
5) Set config enable_plugins=0
6) Check all parts of the plugin are disabled
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
NO_LIBRARY_SET was used when the DB user was logged in. Since bug 20489
it's not longer possible. We could remove the code.
One occurrence left in C4::InstallAuth as there is no (real) logged in user yet.
Test plan:
* Install Koha to make sure NO_LIBRARY_SET is not needed during the
install process
* Login into Koha
* Make sure the your library's name is displayed correctly in the header
* Set another library
* Confirm that the library's name is updated
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
No problem during install, nor changing library.
Fixed (pre-existing) tab in circ/branchtransfers.pl
No errors
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
We certainly faced 3 similar bugs due to this syntax: bug 23006, bug
22941 and bug 17526.
To prevent other issues related to this syntax this patch suggests to
replace them all in one go.
Test plan:
Confirm that the 2 syntaxes are similar
Eyeball the patch and confirm that there is no typo!
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch modifes the process of searching for an existing record
to add to a basket. Now the search is performed as a keyword search in
the regular catalog rather than via a custom search script. Options are
added to the search results and detail pages to add results to an order.
This process follows the same pattern as the "Search to hold" feature:
When the search is initiated, a cookie is set with the requisite
information--in this case vendor id and basket number.
If the search results or bibliographic detail pages detect that a
"searchToOrder" cookie is present, the correct "Add order" link will be
shown. Like with the "search to hold" feature, the cookie expires in 10
minutes.
To test, apply the patch and log into the staff client as a user who has
permission to add to a basket in acquisitions.
- Go to Acquisitions -> Vendor -> Basket -> Add to basket.
- Using the "From an existing record" option, perform a search.
- On the search results page, test the "Add order" link which appears
with each result. Clicking the link should take you to the "New
order" page for the correct vendor and basket. The catalog
details section of the form should include the correct information.
- From the search results page view the bibliographic details page for
any record. There should be a new toolbar button, "Add order." Verify
that it works correctly.
- Test the same thing from all bibliographic detail pages: Normal,
MARC, Labeled MARC, ISBD, as well as the items page
(moredetail.pl).
- Test this process for both the locations in acquisitions where one
can add to an existing basket: Vendor search results and the basket
detail page
- Test the cookie timeout: Wait 10 minutes and perform another catalog
search. The "Add order" link should no longer be present.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
When an invalid bibliographic record is imported into the catalogue
there is not warning or error. However the bibliographic record detail
page will explode (Koha::Biblio::Metadata->record will raise an
exception).
This patch proposes to catch the exception on this view and display a
warning about the situation.
Note that editing/saving the record will fix the MARCXML data and so
removes the warning (some black magic we should get rid of I suspect).
Test plan:
- Import a bibliographic record with invalid XML, you can add non
printable characters, like 0x1F (CTRL-V 1F with vim)
- Go to the detail page
=> Without this patch you get a 500
=> With this patch applied you get a "degraded view" with a warning
message, telling you what the error is.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This minimal class encapsulates the tabs to be passed around to the
templates, so error checking on missing bits is done in a single place.
It throws exceptions on errors
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(Too much javascript in my head...)
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
MDN says:
Using characters except ASCII letters, digits, '_', '-' and '.' may
cause compatibility problems, as they weren't allowed in HTML 4.
Though this restriction has been lifted in HTML5, an ID should start
with a letter for compatibility.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test Plan:
1) Enable plugins
2) Download and install the latest version of this plugin
https://git.biblibre.com/biblibre/koha-plugin-intranet-detail-hook
3) Browse to catalogue/detail.pl for a record
4) Note you see two new tabs with content
Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
Staff side now, go the detail page of a bibliographic record
You should see the cover image.
Sponsored-by: Orex Digital
Signed-off-by: Hayley Mapley <hayleymapley@catalyst.net.nz>
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Kyle Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
- Remove SplitKohaField
- Avoid using Stash in templates
- Improved display of part fields
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
For a biblio with multiple ISBNS we sometimes get our own record back when
check XISBN, we should test for this
To test:
1 - Edit a record in the catalogue, add two isbns:
0521240670
0521284198
2 - Enable ThingISBN and FRBRizeEditions and OPACFRBRizeEditions
3 - View the record in staff and OPAC
4 - You should see editions tab pointing to the same record
5 - Apply patch
6 - Reload the record details, you should no longer see editions tab
7 - Add the second ISBN to another record
8 - Reload details for original record, you shoudl see editions linking to the record with second ISBN
9 - prove -v t/db_dependent/XISBN.t
NOTE: Current tests don't work under elasticsearch, but the code does, tests should be rewritten on another bug
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Bouzid Fergani <bouzid.fergani@inlibro.com>
Signed-off-by: Arthur Bousquet <arthur.bousquet@inlibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Test plan:
1) Ensure the COinS span tag is still included on this pages. You need
to look into html source and search for span tag with class 'Z3988',
which has COinS string in title.
Staff client:
catalogue -> ISBDdetail
catalogue -> MARCdetail
catalogue -> detail
virtualshelves -> shelves
OPAC (you should have COinSinOPACResults system preference enabled):
opac detail
opac search
opac shelves
2) Run tests:
prove t/Biblio.t t/db_dependent/Biblio.t t/db_dependent/Koha/Biblio.t
Signed-off-by: Magnus Enger <magnus@libriotech.no>
Tested with all 9 current patches. Works as advertised, including
OPACURLOpenInNewWindow. If a record has no items, no OpenURL link
is displayed. All the suggested tests pass. I did not test with
XSLT turned off.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch removes the non-XSLT markup from the bibliographic detail
page in the staff client. The XSLTDetailsDisplay preference has
been altered to accommodate this change. A blank value in
XSLTDetailsDisplay will now be equivalent to "default."
To test, apply the patch and set the value of XSLTDetailsDisplay to
either blank or "default."
View the detail page for a bibliographic record in the staff client. The
XSLT view should be shown.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The shelving location can be helpful to locate an item in the library.
Especially, if the library has decided not to create items for a
subscription this information is currently not visible to the patron.
To test:
- Apply patch
- Create a subscription, set location
- View the subscription tab in detail and staff
- Verify that the location now shows above the callnumber
- Unset location in the subscription
- Verify that the page still looks ok
Signed-off-by: Mikaël Olangcay Brisebois <mikael.olangcay-brisebois@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Stephen Graham <s.graham4@herts.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Stephen Graham <s.graham4@herts.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch:
- Removes the unecessary testing for
intranet_catalog_biblio_enhancements method in detail.pl
- Renames get_toolbar_button to get_intranet_catalog_toolbar_button
Signed-off-by: Stephen Graham <s.graham4@herts.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This commit adds hooks into cat-toolbar.inc to allow the display of
arbitrary buttons as supplied by plugins within the
intranet_catalog_biblio_enhancements class that provide the method
get_toolbar_button
To test:
1) Download the plugin from
https://github.com/PTFS-Europe/cla-permissions-check-plugin
2) Follow the installation instructions from:
https://github.com/PTFS-Europe/cla-permissions-check-plugin
3) TEST: Observe that the "CLA Check Permissions" button takes the user
to the Check Permissions page and a modal displays containing the
results of the query
4) Remove the API key from the plugin "Configuration" page
5) TEST: Ensure that the "CLA Check Permissions" button takes the user
to the Check Permissions page and message displays informing the user
that "Did not receive required request parameters"
https://bugs.koha-community.org/show_bug.cgi?id=20968
Signed-off-by: Stephen Graham <s.graham4@herts.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
On the "Acquisition details" tab of the bibliographic detail page, the
subscription information are missing.
This patch replace the call to GetHistory with Koha::Acquisition::Orders
in order to simplify the code and make use of new Koha::
packages/methods.
TODO: Add column settings (show/hide columns) to this table (?)
Sponsored-by: BULAC - http://www.bulac.fr/
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
There is a countanalytics flag that is set for items used in analytical
biblio records. This flag is only used in the template when 'analyze'
has been passed to the script.
In order to avoid unecessary search calls (1 per item), $analyse must be
tested.
Test plan:
0. Do not apply the patch
1. tail -f /var/log/koha/kohadev/zebra-output.log
2. Hit a bibliographic record detail page with several items
3. Notice that the log has 1 line per item:
11:30:36-14/06 zebrasrv(32) [warn] ir_session (exception)
4. Apply the patch
5. Hit the page again
6. There is nothing in the zebra log file
If you are familiar with analytic records, confirm that you are not
allowed to remove an item that is used in analytical biblio records.
Signed-off-by: Hugo Agud <hagud@orex.es>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
If you do not use the EasyAnalyticalRecords feature (introduced with
bug 5528), you will have a lot of warnings in zebra-output.log like:
zebrasrv(1096) [request] Search biblios ERROR 114 1 1+0 RPN @attrset Bib-1 @attr 1=8911 259186
They come from C4::Items::GetAnalyticsCount called by catalogue/detail.pl.
This sub starts a Zebra search on index 'hi' (Host-Item-Number).
If you do not use this field at all (related to 773$9 in MARC21), Zebra
returns an Unsupported Use attribute error (114).
In making this change, I added one minor change:
[1] Remove the commented GetAnalyticsCount in additem.pl and correcting
indentation in that loop (removing tabs). So no change at all there.
NOTE: I will propose to bind the GetHostItemsInfo call in detail.pl and two
other scripts to this preference too on report 20702.
Test plan:
[1] If you use EasyAnalytics, verify that there is no change.
[2] If you do not, check the zebra-output.log. You should no longer see
searches for Host-Item-Number with 1=8911. (As well as ERROR 114 on
this index.)
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Charles Farmer <charles.farmer@inLibro.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
The same pattern was used in other files, this patch fixes it.
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Koha didn't check for a linked authorised value category for
Koha didn't check for a linked authorised value category for
items.materials correctly which led to displaying false information
on the detail page.
To test:
- before applying the patch:
- make sure sample data and configuration is loaded
- edit any item
- write 2 in the $3 materials specificed
- check the details page normal view - it will display 'restocking'
- apply patch
- check display, it should now show "2"
- link 952$3 (MARC21) to ORDER_CANCELLATION_REASON
- check display again, it should now show 'restocking'
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This reverts commit a67fdf3bd4.
I am not sure we already agreed on that: the UI let the ability to
choose different AV category for each frameworks. I think it should be
discussed widely before removing this possibility.
Even if I am pretty sure it is not handle correctly everywhere.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To test:
1 - grep get_biblionumber_from_isbn
2 - verify all occurences are not actual calls (except for test)
3 - Apply patch
4 - grep get_biblionumber_from_isbn
5 - Verify it is removed
Signed-off-by: Roch D'Amour <roch.damour@inlibro.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Actually catalog detail page shows for damaged and lost items the authorized value description if exists.
We must do the same for withdrawn information.
Test plan :
1) Set for items a subfield linked to items.withdrawn and using the authorized value category 'WITHDRAWN'
2) Edit the authorized value category to add value '2' and description 'Eaten by dog'
3) Edit an item to set this withdrawn value
4) Go to staff interface and look at items in record detail page /cgi-bin/koh/catalogue/detail.pl :
=> Without patch you see 'Withdrawn' and with patch you see 'Eaten by dog'
5) Go to OPAc and look at items in record detail page /cgi-bin/koha/opac-detail.pl :
=> Without patch you see 'Withdrawn' and with patch you see 'Eaten by dog'
Signed-off-by: delaye <stephane.delaye@biblibre.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
There is already a HidePatronName syspref to hide patron's information
on bibliographic
record detail pages and the hold list.
Test plan:
With the HidePatronName enabled, make sure the patron's information are
hidden from
the catalogue and hold list pages. If the logged in user is not allowed
to see the
patron's info, no link and no cardnumber will be displayed
With he HidePatronName disabled, make sure the patron's information are
displayed
if the logged in user is allowed to see the patron's info.
Technical note:
This patch improves the existing patron-title.inc include file to
display patron's
information. Using it everywhere patron's details are displayed will
permit to
homogenise the way they are displayed. The file takes now a patron
object (what
should be, in the future, the only way to use it), that way we can call
the new
method on it to know if patron's information can be shown by the logged
in used.
NOTE: I am not sure this syspref makes sense anymore. Should not we
remove it?
Signed-off-by: Signed-off-by: Jon McGowan <jon.mcgowan@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Change parameters to a hashref.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Looks good to me.
Two calls in migration_tools/22_to_30 still in old style.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
GetMember returned a patron given a borrowernumber, cardnumber or
userid.
All of these 3 attributes are defined as a unique key at the DB level
and so we can use Koha::Patrons->find to replace this subroutine.
Additionaly GetMember set category_type and description.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Lari Taskula <lari.taskula@jns.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
On the same way of Koha::Biblio->get_holds,
Koha::Biblio->get_holds_placed_before_today and Koha::Patron->get_holds,
this new subroutin will permit to retrieve the holds placed on a
specific item.
Note that at the moment we do not need a Koha::Item->get_holds method:
we do not want to display future holds placed in the future.
Test plan:
I would suggest to test this patch with patches from bug 17736 and bug 17738,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The C4::Reserve::GetReservesFromBiblionumber took 3 parameters, the
biblionumber, an optional itemnumber and a "all_dates" flag.
If set, the subroutine returned all the holds placed on a given bibliographic
record, even the ones placed in the future. Almost all of the calls had this
flag set, they will be replaced with a call to Koha::Biblio->holds.
But 5 did not have it:
- C4::Biblio::DelBiblio
-tools/batch_delete_records.pl
=> These 2 were wrong, we want to retrieve the holds to cancel them
before deleting the record. We need to get all the holds, even the ones
placed in the future /!\ CHANGE IN THE BEHAVIOR
- acqui/parcel.pl
=> 1 call per item were made to this subroutine. They have been replaced
with only 1 call to the new method Koha::Biblios->holds_placed_before_today
Then we filter on the itemnumbers.
I think this is wrong: we need the number of holds to know if the record
can be deleted, so even if future holds exist, the deletion should not
be possible.
- serials/routing-preview.pl
- C4::ILSDI::Services::GetRecords
- C4::SIP::ILS::Item->new
=> Seems ok, we just one to display holds placed before today
Test plan:
I would suggest to test this patch with patches from bug 17737 and bug 17738,
to place different kind of holds (biblio and item level, future and
past).
Then do a whole workflow to detect bug, view a record, delete record,
order, place a hold on an item which has been ordered, etc.
The hold's informations should always be the same without or without
these patches.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Members::GetHideLostItemsPreference can easily be
replaced with Koha::Patron->find(42)->category->hidelostitems
Test plan:
Create 2 patron categories, 1 with "Lost items in staff client" set to
"shown" and another one to "Hidden by default"
Create 2 patrons using them
On the result search page, the detail page of a record, the item list
page and the page to place a hold, make sure the lost items are
shown/hidden as expected
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Ok I am silly, we needed to replace to use the cache mechanism for
search_by_koha_field, not find_by_koha_field...
Let's create another subroutine
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch replaces the call to C4::Koha::GetKohaAuthorisedValues with
Koha::AuthorisedValues->search_by_koha_field
Test plan:
AV descriptions should be displayed on the following pages:
- XSLT view - location and ccode
- Bibliographic detail, moredetail and OPAC pages - location, ccode, copynumber
- returns - location
- opac-basket - ccode, location
- The 3 reports: catalogue_stats.pl, issues_stats.pl and
reserves_stats.pl - location, ccode
Signed-off-by: Claire Gravely <claire_gravely@hotmail.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
GetAuthValCode did not return anything if the authorised_value column
was not defined. Our new calls to Koha::MarcSubfieldStructures->search
should behave the same
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The subroutine C4::Koha::GetAuthValCode returned the authorised value
category for a given kohafield.
This can be acchieve easily using a new Koha::AuthorisedValues->search_by_koha_field
method which will mimic search_by_marc_field.
Test plan:
Confirm that the description is correctly displayed on the following
pages:
- detail and moredetail of a bibliographic page (itemlost, damaged, materials)
- Set AcqCreateItem=ordering and receiving items.
The description for notforloan, restricted, location, ccode, etc.
field should be displayed.
- Items search form
- On the checkout list from the circulation.pl and returns.pl
pages, the description for "materials" should be displayed
Note that GetKohaAuthorisedValuesMapping is going to be removed on bug
17251.
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is the fourth and last patch set to remove C4::Branch.
The real purpose of this patch is to standardise and refactor some code
which is related to the libraries selection/display.
Its unconfessed purpose is to remove the C4::Branch package.
Before this patch set, only 6 subroutines still existed in the C4::Branch
package:
- GetBranchName
- GetBranchesLoop
- mybranch
- onlymine
- GetBranches
- GetBranch
GetBranchName basically returns the branchname for a given branchcode.
The branchname is only used for a display purpose and we don't need to
retrieve it in package or pl scripts (unless for a few exceptions).
We have a `Branches` template plugin with a `GetName` method which does
exactly this job.
To achieve this removal, we will use this template plugin and delete the
GetBranchName from pl and pm files.
The `Branches.all()` will now select the library of the logged in user
if no `selected` parameter has been passed.
This new behavior could cause regressions, for instance there are some
places where we do not want an option preselected (batch item
modification for instance), keep that in mind when testing.
GetBranchesLoop took 3 parameters: $branch and $onlymine.
The first one was used to set a "selected" flag, for a display purpose:
select an option in the libraries dropdown lists.
The second one was useless: If not passed or set to 0, the
`C4::Branch::onlymine` subroutine was called.
This onlymine flag was use to know if the logged in user was able to see
other libraries infos.
A patron can see the infos from other libraries if IndependentBranches
is not set OR if he has the superlibrarian permission.
Prior to this patch set, the "onlymine test" was done on different
places (neworderempty.pl, additem.pl, holidays.pl, etc.), including the
Branches TT plugin. In this patch set, this test is only done on one
place (C4::Context::only_my_library, code moved from
C4::Branch::onlymine).
To accomplish the same job as this subroutine, we just need to call the
`Branches.all()` method from the `Branches` TT plugin. It already
accepts a `selected` parameter to set a flag on the option to select.
To avoid the repetitive
[% IF selected %]<option selected="selected">[% ELSE %]<option>[% END %]
pattern, a new `html_helpers` TT include file has been created, it
defines an `options_for_libraries` block, which takes a `selected`
parameter. We could imagine to use this include file for other
selects.
The 'mybranch` and `onlymine` subroutines of the C4::Branch package have
been moved to C4::Context. onlymine has been renamed with
only_my_library. There are only 4 occurrences of it, against 11 before
this patch set.
There 2 subroutines are Context-centric and it makes sense to put them
in `C4::Context` (at least it's the least worst place!)
GetBranches is the tricky part of this patch set: It retrieves all the
libraries, independently of the value of IndependentBranches.
To keep the same way as the existing calls of `Branches.all()`, I have
added a `unfiltered` parameter. If set, the `Branches.all()` will call
a usual Koha::Libraries->search method, otherwise
Koha::Libraries->search_filtered will be called. This new method will
check if the logged in user is allowed to see other libraries or only
its library.
Note that this `GetBranches` subroutine also created a `category` key:
it allowed to get the list of groups (of libraries) where this library
existed. Thanks to a previous patch set (bug 15295), this value was
not used anymore (I may have missed something!).
Note that the only use of `GetBranch` was buggy (see bug 15746).
Test plan (for the whole patch set):
The best way to test this whole patch set is to test with 2 instances: 1
with the patch set applied, 1 using master, to be sure there is no
regression.
It would be good to test the same with `IndependentBranches` and the
without `IndependentBranches`.
No difference should be found.
The tester must focus on the library dropdowns on as many forms as
possible.
You will notice changes in the order of the options: the libraries will
now be ordered by branchname (instead of branchcode in some places).
A special attention will be given to the following page:
- acqui/neworderempty.pl
- catalogue/search.pl
- members/members-home.pl (header?)
- opac/opac-topissues.pl
- tools/holidays.pl
- admin/branch_transfer_limits.pl
- admin/item_circulation_alerts.pl
- rotating_collections/transferCollection.pl
- suggestion/suggestion.pl
- tools/export.pl
Notes for QA:
- There are 2 FIXMEs in the patch set, I have kept the existing behavior,
but I am not sure it's the good one. Feel free to open a bug report and
I will fill a patch if you think it's not correct. Otherwise, remove the
FIXME lines in a follow-up patch.
- The whole patch set is huge and makes a lot of changes.
But it finally will tremendously reduce the number of lines:
716 insertions for 1910 deletions
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Hit
/cgi-bin/koha/catalogue/detail.pl?biblionumber=1<script type="text/javascript">alert("XSS")</script>
/cgi-bin/koha/catalogue/ISBDdetail.pl?biblionumber=1<script type="text/javascript">alert("XSS")</script>
/cgi-bin/koha/catalogue/MARCdetail.pl?biblionumber=1<script type="text/javascript">alert("XSS")</script>
/cgi-bin/koha/catalogue/moredetail.pl?biblionumber=1<script type="text/javascript">alert("XSS")</script>
/cgi-bin/koha/catalogue/labeledMARCdetail.pl?biblionumber=1<script type="text/javascript">alert("XSS")</script>
=> Without this patch you will see the alert
=> With this patch, no more alert
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Edit: fixed catalogue/detail.pl and opac/opac-detail.pl so they use the right
XSLT syspref.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In catalogue/detail.pl and catalogue/moredetail.pl, the
GetAuthorisedValues subroutine is called once per item. It's not needed,
only 1 call is enough.
Test plan:
Edit item and view a catalogue record.
The withdrawn, lost and damaged values should be correctly
displayed/saved.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
From C4::Koha::GetAuthorisedValues
# TODO: the "selected" feature should be replaced by a utility function
# somewhere else, it doesn't belong in here. For starters it makes
# caching much more complicated. Or just let the UI logic handle it, it's
# what it's for.
Indeed, it's not a job for a subroutine, the template should take care of that.
Note that a perf gain could be won with this patch \o/
Test plan:
- Edit an itemtype and check the value of the "Search category" dropdown list
- Edit a patron attribute type and check the value of the "Class" dropdown list
- Detail for a catalogue record, the Status column should be correctly
populated if items are damaged and/or lost
- Item details for a catalogue record, the lost, damaged and withdrawn
value should be correctly displayed
- Edit a patron, the "street type" should be correctly selected
- Create a patron attribute type linked to an authorised value list.
- Edit a patron, set a value for this attribute, edit it again. The
correct value should be selected.
- Search for subscriptions. The 'Location' dropdown list should behave
correctly (select the entry you have choosen before, etc.)
- Edit a subscription, the location dropdown list should select the
correct value.
- Edit and view a suggestion with a 'reason for suggestion' set (you
should have at least 1 OPAC_SUG AV defined)
Followed test plan, works as expected
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
In catalogue/detail.pl, if items.materials is linked to an authorised
values list, show label instead of code.
Test plan:
1/ Create an authorised values list 'MATERIALS' with some values
2/ In default MARC biblio framework, link an item subfield to
'items.materials', and to the AV list 'MATERIALS'
3/ Edit an item and give a value for this subfield
4/ Go to biblio record detail page (catalogue/detail.pl)
5/ In the items table, the authorised value label should be displayed.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
1) Ensure your non-public note field is mapped to the
items.itemnotes_nonpublic database column
2) Edit an item, add a test nonpublic note
3) Verify the nonpublic note is shown in the items table on the Detail view.
sponsored-by: New Zealand Ministry of Education Library
sponsored-by: New Zealand Central Agencies Library
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Removed a stray Data::Dumper
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Same as previously.
For these files it's a bit less obvious.
To make sure these changes won't introduce any regression, check that
the variable returned by GetMember is never used to get something
else than a borrower fields.
The 'flags' should not be get neither.
For opac-user.tt it's different, other keys are got but there are defined
in the pl script.
On the way:
- 'showname' is removed (never used)
- fix scope var issue in opac-user.tt (BORROWER_INF.OPACPatronDetails vs
OPACPatronDetails)
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Alex Arnaud <alex.arnaud@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is no special need to format the date in the perl script.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This bug removes deprecated C4::Dates from catalogue/detail.pl
To test:
Apply patch
Go to Home > Catalog > Details for [some biblio with items and holdings]
Make sure that biblio and Holdings and Acquisition details display as appropriate
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Bug 14879 - Remove C4::Dates from catalogue/detail.pl
Remove forbidden patterns (tab) to pass QA tools
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
If IdependentBranches is ON, to edit/delete items from other branches
you need to be superlibrarian.
Currently a "simple" staff user cannot edit them from the edit item page
but from the catalogue detail page.
The edit links should not be displayed on this table.
Test plan:
O/ Set IndependentBranches to "Prevent".
Create a record and add 2 items:
Set homebranch to L1 for item I1.
Set homebranch to L2 for item I2.
1/ With a superlibrarian user, you should be able to edit both items.
2/ With a "simple" user attached to L1, you should only be able to edit
I1. The edit links should not be displayed for I2.
Note that the checkbox is displayed on the catalogue detail page (item
list), but on the batch tools, it won't be possible to select non-modifiable
items.
TODO: Add a server-side check. Indeed it is still possible to edit an
item if the user know the url.
Followed test plan. Works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
First, it is strongly recommended to set the OPACBaseURL. But
this patch allows the inclusion of the protocol and not just
a site.
Next, C4/Auth now puts OPACBaseURL into the template parameters
regardless of OPAC or Staff clients. t/db_dependent/Auth.t was
tweaked to add a check for confirming that get_template_and_user
adds OPACBaseURL to both OPAC and Staff templates.
In the staff client, once the OPACBaseURL is set, you get a nice
OPAC View link when viewing a biblio's detail. It should reflect
the protocol used now.
Hard coded 'http://' strings were removed from the
sample_notices.sql files. This is what required also updating
the letters table in the updatedatabase.pl script.
The explanation text in the sysprefs.sql needed updating too to
reflect the inclusion of the protocol. And this was the other
update done in the updatedatabase.pl script. The opac.pref file
was similarly changed as well.
catalogue/detail.pl had no need to pass a custom OpacUrl value,
since C4/Auth passes the required OPACBaseURL, so it and the
corresponding template were modified.
Both the MARC21 and NORMARC intranet details files had 'http://'
hard coded in them. This was removed.
Both the bootstrap and prog theme opac-detail template had a
protocol parameter that was used. The logic for the parameter
was not removed, because it is used extensively in one template.
Perhaps it should be used to simplify the other. However, the
calculated current_url parameter had references to the protocol
removed, because of the changes to OPACBaseURL.
opac/opac-shareshelf.pl had a hard coded 'http://' which was
removed.
t/db_dependent/Auth_with_cas.t had 'http://' added to the value
set for OPACBaseURL.
In virtualshelves/sendshelf.pl explicit code which sent the
OPACBaseURL preference was removed, since C4/Auth sends it all
the time now.
C4::Context::set_preference was tweaked to ensure that
OPACBaseURL would always start with http.
t/db_dependent/Context.t was tweaked to specifically test this.
The Shibboleth authentication needs OPACBaseURL set, and that
it be https protocol. The _get_uri routine was tweaked to always
pass back https:// as the protocol on the OPACBaseURL.
t/Auth_with_shibboleth.t was tweaked to specifically test the
changes.
TEST PLAN
---------
This is not an easy patch to test. Difficulties include:
- configuring Koha to run under https
(tweaking apache2 isn't so hard, just tricky)
- configuring Koha to run OPAC and Staff with Plak
(since code with comments about plak were sliced out)
- configuring Koha to use CAS
(may be requires for the CAS test)
1) Apply patch
2) Make sure OPACBaseURL is set without the protocol included.
UPDATEDATABASE
3) back up your DB
4) ./installer/data/mysql/updatedatabase.pl
-- It should run without errors.
5) Look up the OPACBaseURL system preference in the staff
client
-- It should have http:// prepended.
6) Run the mysqlclient from your koha git directory
USE koha_library;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
-- There should be no prepended http:// on the
<<OPACBaseURL>>.
7) restore your DB
8) Make sure OPACBaseURL is set with the protocol included,
preferably https.
-- Using https requires a bunch of apache2 tweaks.
AUTH
9) Call up staff client.
10) Call up OPAC.
-- C4/Auth.pm doesn't barf.
11) Call up Plack staff client
12) Call up Plack OPAC.
-- C4/Auth.pm doesn't barf.
13) prove -v t/db_dependent/Auth.t
CONTEXT
14) Home -> Koha administration -> Global System Preferences
-> OPAC
15) Modify and save OPACBaseURL to not have http:// or https://
on it.
-- It should be modified to include http://
16) Modify and save another system preference.
-- It should save normally
17) prove -v t/db_dependent/Context.t
CATALOGUE/DETAIL (tt & pl)
18) Confirm the OPACBaseURL is set
19) Navigate to any biblio details in the staff client
-- There should be a "OPAC view" link which has the
correct http:// or https:// in it.
SQL (sample notices and sysprefs)
20) Run the mysqlclient from your koha git directory
USE koha_library;
DELETE FROM letter;
source installer/data/mysql/de-DE/mandatory/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/en/mandatory/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/nb-NO/1-Obligatorisk/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/es-ES/mandatory/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/fr-FR/1-Obligatoire/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/it-IT/necessari/notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/pl-PL/mandatory/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/ru-RU/mandatory/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
DELETE FROM letter;
source installer/data/mysql/uk-UA/mandatory/sample_notices.sql;
SELECT content FROM letter WHERE content LIKE "%<<OPACBaseURL>>%";
-- Each of the selects should should lines that have
<<OPACBaseURL>> starting them, but no hard-coded http://
DELETE FROM systempreferences;
source installer/data/mysql/sysprefs.sql;
SELECT * FROM systempreferences WHERE variable='OPACBaseURL';
-- The explanation should reflect the new explanation.
QUIT
21) restore your DB
22) Make sure OPACBaseURL is set with the protocol included,
preferably https.
-- Using https requires a bunch of apache2 tweaks.
SLIM2INTRANETDETAIL
23) Set 'XSLTDetailsDisplay' system preference to default.
24) Set 'marcflavour' system preference to MARC21.
25) View any biblio's details.
-- the URL beside 'OPAC View' should have the appropriate
http:// or https://
26) Set 'marcflavour' system preference to NORMARC.
27) View any biblio's details.
-- the URL beside 'OPAC View' should have the appropriate
http:// or https://
OPAC-DETAIL
28) Set 'opacthemes' to bootstrap.
29) Set 'SocialNetworks' to enabled.
30) In OPAC, view any biblio's details.
-- the Share links should have the appropriate protocol on
the OPACBaseURL.
31) Set 'opacthemes' to prog.
32) In OPAC, view any biblio's details.
-- the Share links should have the appropriate protocol on
the OPACBaseURL.
AUTH_WITH_CAS
33) prove -v t/db_dependent/Auth_with_cas.t
OPAC-SHARESHELF
34) Set 'OpacAllowSharingPrivateLists' to allow.
35) In OPAC, 'Save to Lists' a search result.
36) Save it to a new private list.
37) Click the Lists button, and select the new list.
38) Click the Share button.
AUTH_WITH_SHIBBOLETH
39) prove -v t/Auth_with_shibboleth.t
-- needs to be tests on Debian, because I can't get
the Test::DBIx::Class installed in Ubuntu. :(
Rebased again on kohadevbox...
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch adds stocknumber (named Inventory number in interface)
to details table and items display if it exists.
Test scenario:
1. find item(s) which have inventory number assigned
2. verify that you don't see inventory number in items display
3. apply this patch
4. verify that inventory number is now available
Signed-off-by: Nicole <nicole@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since SearchSubscriptions is the way to search subscriptions, each call
to GetSubscriptions could be replaced by a call to SearchSubscriptions.
Test plan:
Verify following pages display the same thing as before this patch:
- catalogue/detail.pl
- opac/opac-ISBDdetail.pl
- opac/opac-detail.pl
Verify the following page returns correct results:
- serials/checkexpiration.pl
Verify the Serials UT file still passes:
- prove t/db_dependent/Serials.t
Note: The title filter on checkexpiration now only searches on the title
DB field. I don't think it is a regression, it should be the way to use
this field. Maybe should we add new search fields on this form.
Bug 5337 reintroduces a bug fixed by bug 5864, this patch restore the
right way to search subscription (based on biblionumber).
Signed-off-by: Aleisha <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
GetHistory iterated on the orders to calculate the quantity and price.
These values are never used by the called.
It can be removed.
Test plan:
Verify there is no regression on acqui/histsearch.pl and
catalogue/detail.pl
Actually you just have to check that the total quantity and price are
not displayed on these views.
QA: note that 'count' and 'toggle' are never used in the template.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
The template params holds and holdcount are not used in the ISBD template.
Removed the associated code from catalogue/ISBDdetail.pl.
Same applies for catalogue/MARCdetail.pl and labeledMARCdetail.pl.
Same applies also for catalogue/imageviewer.pl.
Same applies also for catalogue/moredetail.pl.
In catalogue detail.tt only the number of holds is used. Removed the code
that passed the holds array to the template.
For consistency opac-detail should also incorporate future holds into its
holds count; added the all_dates parameter for that reason.
The Reserves module is no longer needed in moredetail. Removed it. Checked
the other scripts also.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The return from GetReservesFromBiblionumber contains an unnecessary
extra variable. In scalar context an array returns its element count.
Maintaining a separate count can lead to unforeseen bugs
and imposes ugly constructions on the subroutine's users.
Remove the useless count variable from the return
This patch also changes the parameters: now the routine takes a hashref.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Placed biblio holds, future holds and item holds. Works as expected.
Tested Holds.t and Reserves.t. Pass.
Tested /cgi-bin/koha/ilsdi.pl?service=GetRecords&id=999 with two holds on
one item. Fine.
C4/SIP/ILS/Item.pm: Looked for "whatever" and "arrayref" and could not find
them anymore. Looks good.
Handled a few unneeded calls in QA follow-up.
Left only one point to-do for serials/routing-preview.pl. See Bugzilla.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
The list of links to items from the acquisitions tab can be
unwieldy if an order was used to purchase a lot of them, and the
availability of AcqItemSetSubfieldsWhenReceived and filters on the
holdings table provide alternative ways to do things like turn
off on-order statuses.
Test plan:
- verify this patch does not introduce regression on the enhancement
introduced by bug 8230.
- verify the itemnumber list does not appears anymore.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
The acquisitions details tab on the holdings table in the staff
client no longer shows the links to the items. Tests pass.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
In my tests the itemnumbers didn't show up on the acquisition
detail tab before the patch. So the patch visually only changed
the column header for me. All other acquisition related information
showed up ok.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
1/ CURRENT_DATE() is a MySQLism and should be replaced with CAST(now() AS
DATE).
2/ The date formatting should be done in the template (using the TT
plugin).
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Before bug 9788 the alldates parameter of GetReservesFromItemnumber was
actually not used in the codebase.
The first patch of bug 9788 did change that and passed true by default.
But a closer look revealed that we do not really need it.
The parameter is removed by this patch; the SQL statement is slightly
adjusted: if reservedate<=now or a waitingdate is filled for the
requested itemnumber, GetReservesFromItemnumber will return the reserve.
This includes so-called future waits: a future hold that has been confirmed
ahead of time with pref ConfirmFutureHolds > 0 days.
Note that future item-level holds are not really interesting to return; this
just corresponds to original behavior. Future next-available holds are not
in view at all; they do not contain an item number.
Test plan:
Actually, the test plan of the first patch is valid. But for completeness I
repeat it here:
[1] Enable future holds and set ConfirmFutureHolds to 2 days.
[2] Place a future next-available hold for 2 days ahead.
[3] Check item status on catalogue detail. Available? That is fine.
[4] Confirm the future hold by checking it in. ('future wait')
[5] Look at item status again on catalogue detail. Must be Waiting now.
[6] Switch to OPAC and login as another opac user. Goto Place a hold.
[7] Check item status with item level hold info. Is it waiting?
[8] Try to place hold in staff, check item level status again. Waiting?
[9] Make a transfer for the item. Switch branch. Check hold status on
Transfers to receive.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch makes GetReservesFromItemnumber also returns the waiting
date and removes some repeated code.
Improves item status display on catalogue detail, when placing a hold at
opac-reserve and in staff, and on transfers to receive form.
This patch builds on work from reports 9367 and 9761.
Test plan:
Place a future next-av. hold (enable future holds prefs), say 2 days ahead.
Check item status on catalogue detail. Nothing to see.
Enable ConfirmFutureHolds by inserting a number of days, say 2.
Confirm earlier hold by checking it in. Look at item status again on detail.
Switch to other opac user. Try to place a hold again. Check item status with
item level hold info. Try to place hold in staff, check item level status.
Make a transfer for that item. Switch branch. Look at transfers to receive.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds a new tab "Acquitition details" on the catalogue detail
page. It provides a list of order made for this biblio.
New system preference:
AcquisitionDetails: Hide/Show the new tab. The default for
new and upgraded installations is to display the new tab.
Test plan:
1/ Apply the patch.
2/ Select the "placing an order" value for the AcqCreateItem pref.
3/ Create a new order with X items.
4/ Go on the catalogue detail page for the selected biblio.
5/ Click on the "Acquisition details" tab and check that your order is
displayed. Itemnumbers are present in the last column. Check that links
are not broken.
6/ Close your basket.
7/ Status become "Ordered"
8/ Receive X-1 items.
9/ Come back on the catalogue detail page. There are 2 orders: 1
complete and 1 partial. The complete one has a receive date.
10/ Receive the last item.
11/ Now you have 2 orders with a complete status.
12/ Cancel the last receipt.
13/ You have 1 ordered and 1 complete (2 items).
14/ Cancel the first receipt.
15/ You have 1 ordered (3 items).
16/ Delete your order
17/ You have 1 deleted order.
18/ Switch the AcqCreateItem pref to "receiving an order"
19/ Do again steps 3 to 17.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Currently, anyone can delete a record used in an order.
With this patch, only librarians with managing order permission
can delete it if it is used in an active or a deleted order.
This patch also add a specific warning informing that deleting a record
used in an active order is dangerous.
To test :
A. test what can do and see a librarian with order managing rights
0) Connect to Koha with a borrower with order managing rights
1) in a basket, create 2 orders A & B from new records
2) delete order B
3) in the catalogue, try to delete
- record used for order A : you should see a specific warning
informing you the record is used in 1 order, and that deleting it
is dangerous
- record used for order B : you should see a specific warning informing
you the record is used in 1 deleted order
- a record not used in any order : you should see no specific warning
B. test what can do and see a librarian without order managing rights
4) Connect to Koha with a borrower without order managing rights
5) in a basket, create 2 orders A & B from new records
6) delete order B
7) in the catalogue, try to delete
- record used for order A : you should see a specific warning informing you that
you need specific rights to delete the record
- record used for order B : idem
- a record not used in any order : you should see no specific warning
Signed-off-by: Pierre Angot <tredok.pierre@gmail.com>
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch add a column in the items table of catalogue/detail.pl that
contains checkboxes for item selection and a drop-down list of actions
that can be executed for the selection of items.
Currently available actions are:
- Delete selected items: redirect to batch items deletion
- Modify selected items: redirect to batch items modification
Item selection is only enabled if the new syspref
StaffDetailItemSelection is ON.
Actions are not displayed if user doesn't have the right permissions.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Further testing notes on last patch.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
