This patch brings the CatalogConcerns feature to the staff client
allowing non-cataloguers to report issues with catalog records from the
record details page.
Test plan
1) Enable the new `CatalogConcerns` system preference
2) Confirm that without the `edit_catalogue` permission your user can
submit a catalog concern via `New -> New catalog concern` from the
toolbar on a records detail display.
3) Confirm that the right user was recorded as the reporter on the
catalog concern management page (You must have logged in again as a
user with the `edit_catalogue` permission to see this page.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an optional cataloger notification to email the
cataloging team whenever a new catalog concern is reported.
Test plan
1) Enable `OpacCatalogConcerns`
2) Add at least one email address to the new `CatalogerEmails`
prefernce (a comma delimited list is also allowed).
3) Confirm that a default template has been added to the Notices
management, `TICKET_NOTIFY`.
4) Submit a new concern using the OPAC
5) Confirm that an email is sent to those email addresses listed in
CatalogerEmails.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds a catalog concern management page to the staff client
accessible via the cataloging home page and a new 'Pending catalog
concerns' link on the front page.
This includes added the requisit ticket_updates api endpoints and notice
triggers and templates for notifying patrons of changes to their
reported concerns.
Test plan
1) Enable the `OpacCatalogConcerns` system preference
2) Catalog concern management is tied to your users ability to edit the
catalog, `editcatalogue`.
3) Confirm that you can see 'Catalog concerns' listed on the cataloging
home page if you have the `editcatalogue` permission and not if you
do not.
4) Add a new concern as an opac user.
5) Confirm that once a concern is present in the system you see a count
of 'catalog concerns pending' on the intranet main page if you have
the `editcatalogue` permission.
6) Click through either the cataloging home page or pending concerns
link on the main page to view the new concerns management page.
7) Confirm the table displays as one would expect.
8) Confirm clicking on details or the concern title exposes a 'details'
modal with the option to add an update or resolve the concern.
9) Verify that if selecting 'notify' when updateing or resolving a
concern triggers a notice to be sent to the opac user who first
reported the issue.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds an acknowledgement notice that will be sent to the opac
user upon submission of a catalog concern report.
Test plan
1) Confirm that a new notice template is added to the notices management
page.
2) If using a sandbox, check the 'email log' from the management UI to
see the resultant notice has been 'sent'
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds configurable help text and a template option to the
catalog concern report modal in the OPAC.
Test plan
1) Enable `OpacCatalogConcerns` preference
2) Build the CSS for the OPAC
3) Check that there is a 'CatalogConcernHelp' block listed in the HTML
Customisations page.
4) On the OPAC navigate to a record and click the 'Report a concern'
button.
5) Confirm that the content of 'CatalogConcernHelp' displays beneath the
detail entry box and that it displays as expected.
6) Check that there is a 'CatalogConcernTemplate' block listed in the
HTML customisations page.
7) On the OPAC 'Report a concern' modal, you should see the content of
the 'CatalogConcernTemplate' block pre-filled in the details
textarea.
Note: There is a caveat to the template.. as textarea can only be used
to submit plaintext with this patch and as such the template needs to
not utilise the WYSIWYG editor else you will be faced with raw HTML
inside your textarea.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the ability for patrons to report catalog concerns via
the opac.
Test plan
1) Enable the new `OpacCatalogConcerns` system preference
2) Navigate to the record details page of a biblio record on the OPAC
3) You should see a new 'Report a concern' option in the right side
actions box
4) If not logged in you should have the login modal displayed and upon a
successful login you should be redirected back to the details page
with a new model displayed for entering concern details
5) Submit your concern with a title and details.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Enabling this preference should allow catalog concerns to be added by
logged in patrons on the opac.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds basic CRUD API's for the ticket endpoints.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds new Koha::Object(s) for the newly introduced tables,
including updateing existing Koha::Objects adding new relations as
required.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the new `tickets` and `ticket_updates` tables for
tracking catalog concern tickets.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
You should not call this in list context anymore after
bug 29844.
Test plan:
Check pod of Bookseller.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
In search_for_data_inconsistencies.pl, the test for authorized values is a list in one line :
* The Framework *VR* is using the authorised value's category *LOC*, but the following items.location do not have a value defined ({itemnumber => value }):
{94 => AV} {95 => AV} {96 => AV} {97 => AV} {98 => AV} {99 => AV} {100 => AV} {101 => AV} {102 => AV} {103 => AV}
It would be more clear with new lines, especially for scripts (grep, awk ...) :
* The Framework *VR* is using the authorised value's category *LOC*, but the following items.location do not have a value defined ({itemnumber => value }):
{94 => AV}
{95 => AV}
{96 => AV}
{97 => AV}
{98 => AV}
{99 => AV}
{100 => AV}
{101 => AV}
{102 => AV}
{103 => AV}
Test plan :
1) In koha-testing-docker
2) Delete in authorized values LOC the value AV
3) Run misc/maintenance/search_for_data_inconsistencies.pl
=> You see the new line in result
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
See also bug 32612.
The output option includes the stdout.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
dateaccessioned.pl must pick today's date when the input gets the focus
on.
Test plan:
Edit an item, or create a new one.
Confirm that today's date is prefilled into the date's input when it's
empty and that it gets the focus on
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Michael Adamyk <madamyk@ckls.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Use event parameter
This is part of the refactoring happening in bug 30975
Test plan:
1. Verify that the plugin continues to work as before
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Use event parameter
This is part of the refactoring happening in bug 30975
Test plan:
1. Verify that the plugin continues to work as before
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When a record has multiple ISBNs the database stores them seperated by a
pipe
Zebra interprets a string like "isbn:1600213510 | 9781600213519" as an 'OR' search, but for
Elasticsearch we need to explicitly send "OR" - and Zebra support this
as well
To test:
1 - Make sure you are using Elasticsearch
2 - Cataloging->Add a new record from Z3950
3 - Choose target: LOC
4 - Search for: Control number: 14455023
5 - Import and save
6 - Search for the record again
7 - Import and save - duplicate check isn't been triggered
8 - Apply patch
9 - restart_all
10 - repeat 2-7
11 - this time you should get a duplicate notification
12 - Sitch SearchEngine syspref to 'Zebra'
13 - repeat 2-7
14 - Ensure you still get duplicate notification
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch simply ensures we return the job id even if we couldn't send
the job to rabbit.
To test:
1 - In KTD: sudo service rabbitmq-server stop
2 - sudo koha-worker --stop kohadev; sudo koha-worker --queue long_tasks --stop kohadev
3 - In staff client enqueue a batch item modification - note the link to view the enqueued job has no id in the url and takes you to the main background jobs viewer
4 - Run t/db_dependent/Koha/BackgroundJob.t and notice that it fails.
5 - Apply patch
6 - Restart all
7 - Enqueue a new batch item modification
8 - Confirm the link works and has the correct id
9 - Run t/db_dependent/Koha/BackgroundJob.t; it should pass now.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Placing a hold at the OPAC explodes with a 500 when the record is a
serial
DBIx::Class::Storage::DBI::_dbh_execute(): DBI Exception: DBD::mysql::st execute failed: Column 'biblionumber' in where clause is ambiguous at /usr/share/koha/lib/Koha/Objects.pm line 394
Test plan:
* Create a serial subscription for an existing bibliographic record
* Place a hold on this record at the OPAC
Signed-off-by: Janusz Kaczmarek <januszop@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds the missing 'Provider name' parameter definition to the
various ERM paths that were missing it.
Test plan
1) Run:
docker run --rm -v $PWD/api/v1/swagger:/swagger \
jeanberu/swagger-cli \
swagger-cli validate swagger/swagger.yaml
=> FAIL: The spec is not valid!
2) Apply this patch
3) Repeat 1
=> SUCCESS: Tests pass!
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Edit: tcohen edited the test plan because of the failure to install
swagger-cli cleanly
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds a reaosn parameter and passes it into the cancellation if supplied
To test:
1 - Place a hold for a patron in your system
2 - Run script with --days 0 -v
3 - verify that it would cancel the reserves (and that you are okay with cancelling the ones it found)
4 - Make sure you have a notice in the holds module with code 'HOLD_CANCELLATION'
5 - Set content of the notice like:
[% IF hold.cancellation_reason=='too_old' %]
Canceled old
[% END %]
6 - Run script with --days 0 -v --reason too_bad -c
7 - Confirm hold cancelled, no notice sent to patron
8 - Place another hold
9 - Run script with --days 0 -v --reason too_old -c
10 - Confirm hold cancelled, notice sent to patron
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This change harmonizes the patron streetnumber input between
the staff interface and the OPAC, so that you can only enter 10
characters into the streetnumber for the OPAC. Without this change,
a fatal error will be thrown trying to save the too long data.
Test plan:
0. Apply the patch
1. Go to http://localhost:8080/cgi-bin/koha/opac-memberentry.pl
2. Note that you can only enter 10 characters into the "Street number"
field as a self-registration patron
3. Log into Koha
4. Go to http://localhost:8080/cgi-bin/koha/opac-memberentry.pl
5. Note that you can only enter 10 characters into the "Street number"
field when editing logged in patron details too
6. Go to http://localhost:8081/cgi-bin/koha/members/memberentry.pl?op=add&categorycode=S
7. Note that you can only enter 10 characters into the "Street number"
field as a staff member
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Solene Ngamga <solene.ngamga@inLibro.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Make one API call for all AV categories+values instead of one API call per AV category required
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 32981 let us retrieve the authorised values from a REST API route,
instead of injecting them from the template. Let us that for the ERM module!
Test plan:
You will notice a "Loading" screen when refreshing the ERM module
Then you should not notice any other UI changes. Dropdown list should be
populated like before this patch.
Some technical notes:
I am expecting this to be slower than before, but it feels better to use
a REST API route to retrieve the AV
Future improvement will be to lazy load the AVs, to speed up the landing
page. However it needs more changes, and this gets big enough.
I would like to see a follow-up that move the code from ERM/Main.vue to
the authorised value store (I've failed at that), but that should
certainly be done after the lazy loading is implemented anyway)
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch now checks the status of messages and ignores any message
with a status of 'new'. It is also rebased to account for changes made
to cleanup_database.pl in bug 17350.
Test plan:
1) Ensure you have some EDI orders or even just some dummy messages in the edifact_messages table with a mixture of statuses including 'new'
2) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose (Change the number of days according to the data in your table)
3) The response should show a number of messages that would have been deleted
4) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose --confirm
5) The response should now show the same number of messages have been deleted
6) Check your edifact_messages table to confirm that the data has been deleted
7) Confirm that no messages marked 'new' have been deleted
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Changes a few occurrences of edifact in the output messages
to EDIFACT.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch allows users to clear out old edifact_messages using the cleanup_database script. The number of days can either be set in the CLI or the default value of 365 can be used.
Test plan:
1) Ensure you have some EDI orders or even just some dummy messages in the edifact_messages table
2) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose (Change the number of days according to the data in your table)
3) The response should show a number of messages that would have been deleted
4) Run perl misc/cronjobs/cleanup_database.pl --edifact-messages 100 --verbose --confirm
5) The response should now show the same number of messages have been deleted
6) Check your edifact_messages table to confirm that the data has been deleted
Sponsored-by: PTFS Europe
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To reproduce:
1- Have at least 10 record of the same type that can be viewed from OPAC
2- Go to administration > system preferences > OPACnumSearchResults and set it to 1
3- Go to the OPAC and search for the type from step 1
4- Notice top and bottom page selections are numbered from 1 to 10 + Next >> + Last >>
5- Inspect the webpage and switch to mobile view
6- Reduce display width and notice the buttons (of step 4) on the right are overflowing the screen
7- Apply the patch
8- compile the .scss file 'yarn build --view opac'
9- Clear your navigator caches
10- repeat step 3,5 and 6
11- Notice the buttons (of step 4) are no more overflowing the screen
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Bug 31221: (fix) Adding "flex-wrap: wrap" to the pagination links in opac.scss
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This enhances the availability search option on item search
to have a third option: ignore, checked out and not checked out.
I chose 'not checked out' as available could be misleading,
the item might still be lost or withdrawn and not on the shelf.
To test:
* Apply patch
* Make sure some items are checked out
* Search with 'ignore' - note number of results
* Search with 'checked out' - note number of results
* Search with 'not checked out' - number of results should
match ignore minus checked out
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch renames that for consistency, and also makes use of the
->authorised_values accessor on the category.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch adds /api/v1/authorised_value_categories endpoint that
retrieves authorised value categories for the given names and their
authorised values if x-koha-embed: authorised_values is also given.
To test:
Apply patch
curl -u koha:koha --request GET \"http://localhost:8081/api/v1/authorised_value_categories?q=%7B%22me.category_name%22%3A%5B%22LOC%22%2C%22YES_NO%22%5D%7D\" --header \"x-koha-embed:authorised_values\"
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
For, at least, the ERM module we would like to retrieve the authorised
values for a given category to build a dropdown list with the different options.
It has been decided on bug 17390 to use
GET /authorised_value_categories/:authorised_value_category_id/values
Test plan:
curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/LOC/values
Should display the list of LOC
curl -v -s -u koha:koha --request GET http://kohadev-intra.mydnsname.org:8081/api/v1/authorised_value_categories/xLOCx/values
Should return a 404
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch corrects the options for the EnableItemGroups and
EnableItemGroupHolds system preferences.
To test:
1. Enable EnableItemGroups and EnableItemGroupHolds system preferences
1.1. Go to Administration > Global system preferences
1.2. Search for EnableItemGroup (no s, to get both)
1.3. Enable both EnableItemGroups and EnableItemGroupHolds
1.4. Click Save all Circulation preferences
2. Go to About Koha > System information
--> There is a warning message
3. Go to a bibliographic record with at least one item
--> The item group tab is displayed
4. Create an item group
4.1. Click New item group
4.2. Enter a name
4.3. Click Submit
4.4. In the Holdings tab, select the item
4.5. Click on Add/move to item group
4.6. Click Set item group
5. Place a hold on the item group
5.1. Click Place hold
5.2. Search for a patron
5.3. In the 'Hold next available item from an item group' section, select the item group
5.4. Click Place hold
--> Placing a hold is possible
6. Disable EnableItemGroups and EnableItemGroupHolds system preferences
1.1. Go to Administration > Global system preferences
1.2. Search for EnableItemGroup (no s, to get both)
1.3. Disable both EnableItemGroups and EnableItemGroupHolds
1.4. Click Save all Circulation preferences
7. Go to About Koha > System information
--> There is a warning message
8. Apply patch
9. Redo steps 1 and 2
--> There is no warning
10. Redo step 3
--> The item group tab is displayed
11. Redo steps 4 and 5
--> Placing a hold is possible
12. Redo steps 6 and 7
--> There is no warning
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
JD Amended commit message: * Commit title does not start with 'Bug XXXXX: '
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It would be very useful to be able to tell process_message_queue.pl to skip processing some messages. This is particularly useful where a plugin handles sending some message using the before_send_messages hook, but while that plugin is processing, more messages meant for the plugin might be queued. At that point, control moves back to the script and SendQueuedMessages is called, and those messages end up being processed there instead of by the plugin.
Test Plan:
1) Apply this patch
2) Queue two messages, each with a unique word
3) Run process_message_queue --where "content NOT LIKE '%WORD%'"
where WORD is a unique word in one of the two message
4) Note the message containing "WORD" was not processed
5) prove t/db_dependent/Letters.t
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch replaces the bootstrap panels with the more modern koha
page-section cards layout.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch drops the superflous div from the ill-list-table include and
instead opts to wrap calls to it with a more appropriately positioned
div instead.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When using an authorised value VENDOR_TYPE for the
vendor type, we should show the AV description
everywhere instead of the code. It already works on
the vendor search, but not on the vendor detail page.
With this patch it will also work there.
To test:
1. Add at least one authorized value in VENDOR_TYPE
1.1. Go to Administration > Authorized values
1.2. Search for VENDOR_TYPE
1.3. Click 'Add'
1.4. Fill out the form
- Authorized value: BOOK
- Description: Print books
1.5. Click 'Save'
2. Add a new vendor
2.1. Go to Acquisitions
2.2. Click 'New vendor'
2.3. Fill out the form
- Name: ABC Bookstore
- Vendor type: Print books
2.4. Click 'Save'
3. Go to the vendor page
3.1. Click on the vendor name
--> The value in "Type" is BOOK, it should be "Print books"
4. Apply patch
4.1. Repeat test, now it should show the description
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The OPAC basket detailed view display is broken since since bug 32445.
This patch restore the usual operation.
TO TEST:
1. Add a biblio recor into the OPAC basket.
2. Click on the cart to display its content.
3. Click on More details
=> error 500
4. Apply the patch, and repeat 3.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch sends out opac-search.osdx without running the entirety
of opac-search.pl without any search query.
This prevents unnecessary computations and warnings from appearing
in the logs.
Test plan:
1. Apply patch
2. Go to
http://kohadev.myDNSname.org:8080/cgi-bin/koha/opac-search.pl?format=opensearchdescription
3. Note that no errors appear in
/var/log/koha/kohadev/plack-opac-error.log
4. Verify that opac-search.pl still works as expected when
doing a search via the web UI
Signed-off-by: David Nind <david@davidnind.com>
JD Amended patch: remove ref to bug number, we use git!
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
0 - Apply first patch
1 - prove -v t/db_dependent/SIP/Patron.t
2 - It fails
3 - Apply second patch
4 - prove -v t/db_dependent/SIP/Patron.t
5 - It passes!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This follow-up removes the required property from the text area as this
was missed previously.
Test plan:
1) In the ERM module, add a new agreement and observe that the Description field is required
2) Apply patch
3) Repeat step 1 but this time the Required flag will not be visible.
4) Submit the form with the Description field blank - the submission
should work
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
There is a couple of wrong things from the previous patch:
* There is a warning in the console
Firefox
[Vue Router warn]: Unexpected error when starting the router: TypeError: document.getElementById(...) is null
Chrome
[Vue Router warn]: Unexpected error when starting the router: TypeError: Cannot read properties of null (reading 'click')
That's because the tabs are not initialized yet, and so the tab is not
correctly selected when the app is loaded.
* "Search titles" is selected when on packages, and "Search packages" is
selected when on titles
This patch remove the warning and fix the second problem.
However the tab is still wrong when the app is loaded. Will see later if
that can be fixed, but it's not trivial at first glance.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>