This patch:
1 - Adds an atomic update to add a primary key to import_auths table
2 - Adds objects for Koha::Import::Records::Auths
3 - Adds tests for import auth and biblio objects
Signed-off-by: Andrew Fuerste-Henry <andrewfh@dubcolib.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When the 773 entry is not linked to a record using $w or
Easyanalytics we still want to display the information
about the source/host item in the emails.
To test:
1. Activate the UseControlNumber system preference
2. Search for a record and make sure it has 001 set to some value.
3. Use Edit > Add child record to create an analytical record from this record.
4. Make sure 773$w was filled in and finish by adding any mandatory fields, save.
5. Add this record to your cart. Also add a 773$g with the pages or similar.
6. Create another record with 773$t and $g, but without $w.
7. Also add this record to your cart.
8. Add a few other records to the cart.
9. Host item information (In: ) should display for all entries with 773 in the record.
This also makes use of the biblio-title include to display the
different parts of the title (245$abnp), if the record is linked.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Incorporating fixes from Bug 16522
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This fixes several issues found and improves formatting:
* Add missing line breaks <br> where required as we are now using HTML
* Add missing USE statements to show
* library
* location
* Link to the OPAC (Preference was not resolved)
* Make sure there is a comma between library and location
* Make sure Author(s): only displays when there is content after
* The comment field allows multi-line comments, formatting is now preserved
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch creates notices using Template Toolkit syntax for sending
emails containing cart and list contents.
To test:
1. Apply Bug 27266
2. Run update database and restart services
3. In the staff client, add multiple items to your cart and to a list
4. Go to your cart and click Send to email the contents
5. Add an email and a comment and click Send
6. Confirm the information shown in the success message is correct
7. In your terminal, log into the database. View the message queue ( i.e. select * from message_queue; ). Confirm that your email has been queued and the content is all correct. Confirm the cart contents has been included as an attachment.
8. Go to your list and click Send list to email the contents
9. Repeat steps 5-7
10. Log into the OPAC
11. Add multiple items to your cart and to a list
12. Repeat steps 4-9
13. By the end, you should have four emails in your message queue. All
of the data about the items should be correct, they should all have
attachments, and be addressed to the correct email address.
Sponsored-by: Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Adds sms sample notice for due, hold, checkin and checkout
Test plan:
1. Check that there are no SMS messages for these notices (Tools > Notices & slips):
. CHECKIN - Item check-in (digest)
. CHECKOUT - Item check-out (digest)
. DUE - Item due reminder
. DUEDGST - Item due reminder (digest)
. PREDUE - Advance notice of item due
. PREDUEDGST - Advance notice of item due (digest)
. HOLD - Hold available for pickup
2. Apply the patch.
3. Update the database (./installer/data/mysql/updatedatabase.pl)
4. Refresh page
5. Check that there are now SMS notices for the notices listed in step 1.
6. Sign-off!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
It can be useful to know where in Koha a particular logged action was generated from, and how. We should add the ability to attach a syspref controlled basic stack trace with the caller depth controlled via the syspref. We can the call caller() until the specified depth has been reached.
Test Plan:
1) Apply this patch
2) Run updatedatabase.pl
4) Restart all the things!
5) Set the new syspref ActionLogsTraceDepth to a number ( e.g. 3 )
6) Update a syspref or trigger another enabled log action
7) Query the database: SELECT * FROM action_logs WHERE trace IS NOT NULL
8) Note the stack trace was created!
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>
To test:
1. Apply patch, updatedatabase, restart_all
2. Have a user with superlibrarian privileges ( User1 )
3. Have a user who has staff access and circulate privileges but is not a super librarian. ( User2 ) Make note of this users home library
4. Turn on the system preference 'CircSidebar'.
-MAIN log in ( auth.tt )
5. As User1, go to the main login screen and try logging in. You should be able to log in AND you should be able to properly chnage your branch BEFORE logging in.
6. As User2, to to the main login screnn amd try logging in. You should be able to but if you try and switch your libraray to anything beside the user's home branch it will not work. You will be logged in at your home branch.
7. For User2, set the new top level permission 'Allow staff to change logged in library (loggedinlibrary).
8. Now you should be able to successfully switch libraries before log in.
9. Turn the 'loggedinlibrary' permission back off for User2.
-AFTER log in-
10. With User1, click on your name/branch in the top right, you should see the the link 'Set library' at the top. If you turn on 'UseCirculationDesks' the link will be 'Set library and desk'.
11. With User2, click on your name/branch in the top right. If you have 'UseCirculationDesks' on, you should see 'Set desk', otherwise you should see nothing.
12. Repeat step 7.
13. NOw if you click on your name/branch in the top right, you should see the the link 'Set library' at the top. If you turn on 'UseCirculationDesks' the link will be 'Set library and desk'.
14. Repeat Step 9.
-CircSideBar-
15. With 'CircSideBar' turned on, go to any ciculation page (Holds queue, Holds to pull, Holds awaiting pickup) with User1. You will see the 'Set library' link. If 'UseCirculationDesks' is on you will see a 'Set library and desk'.
16. Try with User2 and you will not see a 'Set library' link. If 'UseCirculationDesks' is on you will see a 'Set desk' link.
17. Repeat step 7.
18. For with User2 you go to any ciculation page (Holds queue, Holds to pull, Holds awaiting pickup). You will see the 'Set library' link. If 'UseCirculationDesks' is on you will see a 'Set library and desk'.
19. Repeat step 9.
-Set library page-
20. Go to the set library page (http://localhost:8081/cgi-bin/koha/circ/set-library.pl) with User1. You will see a dropdown for 'Set library'. Make sure you can change your library successfully.
21. Go to the set library page (http://localhost:8081/cgi-bin/koha/circ/set-library.pl) with User2. You should NOT see see a dropdown for 'Set library'.
22. Repeat step 7.
23. Go to the set library page (http://localhost:8081/cgi-bin/koha/circ/set-library.pl) with User2. Now you should see a dropdown for 'Set library'.
Signed-off by: Bob Bennhoff/AspenCat Team
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Sponsored-by: The Research University in the Helmholtz Association (KIT)
Signed-off-by: Michaela Sieber <michaela.sieber@kit.edu>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes the addition of html_helpers out of C4::Letters and
into the relevant notice templates where it belongs.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We we're using [% %] rather than [%- -%] in our the notice template
introduced with this patchset. This leads to some interesting rendering
results in some email clients. Using the proper whitespace ignoring
template markup fixes the situation.
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 should resolve the lack of linebreaks in resulting emails
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 updates the notice codes from 'catalog' to 'catalogue' to be
consistent with the existing codebase.
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>
TICKET_ACKNOWLEDGEMENT was too long for the database field size, drop
the 'MENT' to ensure it fits.
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 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>
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 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>
To test:
1) Activate the IllModule system preference
2) Install a backend (BLDSS or FreeForm) following the wiki instructions:
3) Configure some authorised values for ILLSTATUS
4) Apply patch
5) Run database update
6) Verify your configured values have been updated to ILL_STATUS_ALIAS
7) Add another ILL_STATUS_ALIAS: there should now be an explanation in the
categories list
8) Go to the ILL module and add a new request
9) Edit the request, verify that your status alias show in the status list
10) Set one of your status and save
11) Verify that the ILL requests list search filters show your status alias
12) Manage the request again and verify that the ILL request log shows the
status descriptions correctly
13) Verify the description of the ILLHiddenRequestStatuses has
been updated with the new authorised value category
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
* Go to administration > authorised values
* Verify that VENDOR_TYPE doesn't show in the list
* Apply patch
* Run database update
* Verify that VENDOR_TYPE does now appear and has a nice
description (not added by this patch)
* Bonus: start over and run the web installer, VENDOR_TYPE
should now be already there
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 fixes two recalls notices which are referencing old column
names, so they leave empty fields when the notices are generated.
To test:
1) Apply database updates and restart services
2) Go to Tools -> Notices
3) Find the RECALL_REQUESTER_DET notice, open the Print tab
4) Confirm there are no references to recalls.waitingdate or
recalls.recallnotes. Confirm the reference is fixed to
recalls.waiting_date and recalls.notes
5) Find the PICKUP_RECALLED_ITEM notice, open the Email tab
6) Confirm there are no references to recalls.branchcode or
recalls.expirationdate. Confirm the reference is fixed to
recalls.pickup_library_id and recalls.expiration_date
Sponsored-by: Catalyst IT
https://bugs.koha-community.org/show_bug.cgi?id=32697
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch changes the datatype of the field_value column in
marc_modification_template_actions to "text". This is to stop text
strings longer than 100 characters from being chopped short and allow
longer strings up to 65,000 characters.
Test plan:
1) Follow the same steps outlined by Caroline in the problem statement
2) Apply patch
3) Follow the steps again and this time the text should upload with no
problem
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
New column has now been changed to an enum in line with comments and the strings have been amended to be picked up for translation. The file koha-tmpl/intranet-tmpl/prog/en/includes/str/checkout_renewals.inc has been removed as the variables can be included within the javascript file.
Test plan:
1) In the database shell run "show columns from checkout_renewals;" and observe that there is currently no column for recording the type of renewal
2) Apply patch
3) In the shell run "dbic" and "perl installer/data/mysql/updatedatabase.pl" to update the database schema with the new column.
4) Create some checkouts
5) Renew some checkouts manually and observe in the database that there is now a column called "renewal_type" that will have recorded these as "Manual"
6) Create some checkouts that can be automatically renewed
7) Run the cron script in automatic_renewals.pl and observe that there are now also entries with a renewal_type of "Automatic"
8) Send a GET request to http://localhost:8081/api/v1/checkouts/1/renewals and observe that the renewal_type is now returned in the response
9) In the Item Details tab for a record, there is the "Current renewals" option which has a button to view renewals. Click on this and observe that the modal now displays the new information.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
A requirement has been requested to record whether a renewal was done manually or automatically. A column has been added to the checkout_renewals table in the database to record this and a check is now in place to determine whether the renewal was manual or automatic. The API has also been updated to reflect this new column and return the data when requested. The renewals modal view has also been updated to show what type the renewal was.
Test plan:
1) In the database shell run "show columns from checkout_renewals;" and observe that there is currently no column for recording the type of renewal
2) Apply patch
3) In the shell run "dbic" and "perl installer/data/mysql/updatedatabase.pl" to update the database schema with the new column.
4) Create some checkouts
5) Renew some checkouts manually and observe in the database that there is now a column called "renewal_type" that will have recorded these as "Manual"
6) Create some checkouts that can be automatically renewed
7) Run the cron script in automatic_renewals.pl and observe that there are now also entries with a renewal_type of "Automatic"
8) Send a GET request to http://localhost:8081/api/v1/checkouts/1/renewals and observe that the renewal_type is now returned in the response
9) In the Item Details tab for a record, there is the "Current renewals" option which has a button to view renewals. Click on this and observe that the modal now displays the new information.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Without this patch, running the atomicupdate twice crashes on patrons
with edit_items permissions:
C4::Installer::run_atomic_updates(): DBI Exception: DBD::mysql::db do failed: Duplicate entry '19-9-edit_any_item' for key 'PRIMARY' at /kohadevbox/koha/installer/data/mysql/updatedatabase.pl line 24303
DEV atomic update /kohadevbox/koha/installer/data/mysql/atomicupdate/bug_20256.perl [14:26:41]
ERROR - C4::Installer::run_atomic_updates(): DBI Exception: DBD::mysql::db do failed: Duplicate entry '19-9-edit_any_item' for key 'PRIMARY' at /kohadevbox/koha/installer/data/mysql/updatedatabase.pl line 24303
It also aligns this 3yro script with the new structure we've been using.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Test Plan:
1) Apply this patch set
2) Run updatedatabase.pl
3) Create two library groups with some libraries in them,
make sure to enable the new feature to limit editing of items
4) Test the functionality, if an item is owned by a library in
your group, you should have full editing abilities. If an item
is from a different group, you should only be able to make the
same changes you would be able to if IndependentBranches were.
Signed-off-by: Bob Bennhoff - CLiC <bbennhoff@clicweb.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
