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>
As there is no check, this dbrev could cause trouble if run twice. It
doesn't look like it is going to get backported to 22.05, but just in
case...
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This adds new lines between each authorised value for better
readability and to match the formatting of the rest of the file.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch moves the authorized value insertions for ERM categories into
the language-specific auth_values.yml file.
To test:
1. Count the number of authorized values in the mandatory categories
select count(*) from authorised_values where category in ('YES_NO', 'PAYMENT_TYPE', 'HSBND_FREQ', 'ERM_AGREEMENT_STATUS', 'ERM_AGREEMENT_CLOSURE_REASON', 'ERM_AGREEMENT_RENEWAL_PRIORITY', 'ERM_USER_ROLES', 'ERM_LICENSE_TYPE', 'ERM_LICENSE_STATUS', 'ERM_AGREEMENT_LICENSE_STATUS', 'ERM_AGREEMENT_LICENSE_LOCATION', 'ERM_PACKAGE_TYPE', 'ERM_PACKAGE_CONTENT_TYPE', 'ERM_TITLE_PUBLICATION_TYPE', 'COUNTRY', 'LANG', 'qualif');
--> There should be 929
2. Delete the authorized values from these categories
delete from authorised_values where category in ('YES_NO', 'PAYMENT_TYPE', 'HSBND_FREQ', 'ERM_AGREEMENT_STATUS', 'ERM_AGREEMENT_CLOSURE_REASON', 'ERM_AGREEMENT_RENEWAL_PRIORITY', 'ERM_USER_ROLES', 'ERM_LICENSE_TYPE', 'ERM_LICENSE_STATUS', 'ERM_AGREEMENT_LICENSE_STATUS', 'ERM_AGREEMENT_LICENSE_LOCATION', 'ERM_PACKAGE_TYPE', 'ERM_PACKAGE_CONTENT_TYPE', 'ERM_TITLE_PUBLICATION_TYPE', 'COUNTRY', 'LANG', 'qualif');
3. Apply patch
4. Load the mandatory authorized values
./misc/load_yaml.pl --file installer/data/mysql/en/mandatory/auth_values.yml --load
5. Redo step 1
--> There should be the same number (929)
6. Update translations
cd misc/translator
./translate update xx-XX
7. Search the po/xx-XX-installer.po file for any of the loaded
authorized values
For example,
grep "Abstract and index" po/xx-XX-installer.po
--> descriptions should be translatable
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
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>
Fixes the lines for old_reserves.item_level_hold and
reserves.item_level_hold comments to read 'hold'
instead of 'hpld'
To test:
* The easiest way to verify this change is by looking
at the patch itself
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This standardizes "Total Holds" to "Total holds" etc.
Also changed is UNIMARC
* "Collection code" to "Collection" like MARC21
* "Current Location" to "Current library" like MARC21 (holdingbranch)
* "Permanent Location" to "Home library" like MARC21 (homebranch)
To test:
* You'll need to apply the patch and then run the web installer to
create your frameworks
* Once you got a fresh installation, got to
Administration > Bibliographic frameworks > Choose any
* Go to 995 (for UNIMARC) or 952 (for MARC21)
* Check the descriptions of the subfields for capitalization and
spelling errors
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.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>
Bug 22343 adds the ability to defined SMTP servers via the UI; But to then utilise them you have to go to each individual library via the libraries admin area and select the SMTP server.
We should have a way to override the fallback/default SMTP server right from the SMTP servers administration page.. setting one of our defined SMTP Servers as the system default rather than using the hard coded fallback options.
Test Plan:
1) Apply this patch set
2) Restart all the things!
3) Browser to the SMTP servers editor,
verify only one server can be set as the default server
4) Set a default server, verify that server was used to send email from
a cronjob, AND/OR prove t/db_dependent/Koha/SMTP/Server.t
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>
Table background_jobs should have indexes to optimize queries.
Query on borrowernumber :
mainpage.pl: my $already_ran_jobs = Koha::BackgroundJobs->search(
mainpage.pl- { borrowernumber => $logged_in_user->borrowernumber } )->count ? 1 : 0;
Query on status and queue :
misc/background_jobs_worker.pl: my $jobs = Koha::BackgroundJobs->search({ status => 'new', queue => \@queues });
Test plan :
Run updatedatabase and play with background jobs
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Fix MySQL error:
ERROR 1093 (HY000): You can't specify target table 'systempreferences' for
update in FROM clause
introduced by db_rev 064 for bug 14783.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Some users have reported that the dbrev of bug 30483 fails. This might
depend on bad data, SQL server version, etc.
We now remove the constraints temporarily.
Test plan:
Reset your version in order to pass this dbrev again. So below
22.06.00.041.
* update systempreferences set value='22.0600040' where variable = 'Version';
Run updatedatabase.
Bonus: Create an issues record with invalid itemnumber (set FK check
off when doing so). Verify that dbrev fails and installer stops.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
When e- is used as prefix, the second word should not
be capitalized. And when e-resource-management is used
as part of a sentence, the e shouldn't be either.
See: e-mail, e-commerce. etc.
To test:
* Best to check the code... but:
* All E-Resource should now read e-resource or E-resource, as on:
* Koha start page
* Breadcrumbs in the ERM module
* Descriptions of AV categories...
I chose to update the sysprefs.sql and the DB update as well
as this hasn't been released yet.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Bug 32147: (follow-up) Fix missing space
One of the AV category descriptions was missing a space
before the (e-resource management).
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>
