This patch sets a default value for the EDI account form for the upload and download ports
Test plan:
1) Try to create an EDI account without setting the upload or download ports
2) The form will crash
3) Apply patch and restart_all
4) Try again, the form should submit
5) In your new EDI account, you should see the value of 22 for both ports
Signed-off-by: Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
1. Go to Acquisitions > EDI Accounts
2. Create an EDI account if one is not already there
3. Try to delete the EDI account
--> Page refreshes and nothing happens
4. Apply patch, restart_all, and refresh the page
5. Try to delete the EDI account again
--> A confirmation page displays with correct information
6. Click "Yes, delete"
--> The EDI account is deleted
Signed-off-by: Matt Blenkinsop <matt.blenkinsop@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Not all EDI vendors accept Koha servers connecting on port 22, sometimes
they require a different port to be used, so it would be helpful for
librarians to be able to configure non-standard EDI SFTP ports
themselves.
Test plan:
1. Set EDIFACT syspref = 'Enable' and define a EDI account: Administration > Acquisition parameters > EDI
accounts.
2. Create an EDI order: https://koha-community.org/manual/latest/en/html/acquisitions.html#ordering-via-edi
3. Confirm you can upload the EDI order and download the vendor invoice.
4. Apply patches, update database, and restart services.
5. Go to the EDI account you made in #1.
6. Confirm there are two new fields: Upload port and Download port, both
have the value of 22.
7. Create a new EDI order.
8. Confirm you can upload the EDI order and download the vendor invoice.
9. Change the EDI account. Set the Download port = 10022.
10. Create a third EDI order.
11. Confirm you can upload the EDI order and download the vendor
invoice.
Sponsored-by: Waikato Institute of Technology, New Zealand
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch fixes a missing $crypt in the show_account function when deleting an edifact ordering account.
Test plan:
1) In system preferences search for EDIFACT and change EDIFACT to Enable
2) Navigate to Administration > EDI accounts
3) Create a dummy account
4) Try deleting the account using the delete button in the actions column on the far right
5) An error should be thrown - "Can't call method "decrypt_hex" on an undefined value"
6) Apply patch
7) Try deleting the account again
8) This time it should work and show the confirmation dialog box
9) Sign off
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
We are storing edi vendor acccount passwords in clear text in the
database. Now that Koha has the Koha::Encryption module, we should
use that to encrypt passwords for all existing and new EDI accounts.
Test Plan:
1) Apply this patch
2) Create one or more EDI vendor accounts
3) Run a report to view the account passwords, note they are in clear
text
4) Run updatedatabase.pl
5) Re-run the report, account passwords should be encrypted now
6) Edit a vendor EDI account, note you can still view and update the
password for an account
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>
This patch uses the new 'standard' field to in the edifact account
configuration area to allow setting the message standard as either
'EDItEUR' or 'BiC'.
This just replaces the currently hard coded hash of SAN's in
Koha::Edifact::Order to distinguish between the two standards instead of
requireing a bug submission per vender san we identify to be a BiC type
vendor.
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
On bug 17591 we discovered that there was something weird going on with
the way we export and use subroutines/modules.
This patch tries to standardize our EXPORT to use EXPORT_OK only.
That way we will need to explicitely define the subroutine we want to
use from a module.
This patch is a squashed version of:
Bug 17600: After export.pl
Bug 17600: After perlimport
Bug 17600: Manual changes
Bug 17600: Other manual changes after second perlimports run
Bug 17600: Fix tests
And a lot of other manual changes.
export.pl is a dirty script that can be found on bug 17600.
"perlimport" is:
git clone https://github.com/oalders/App-perlimports.git
cd App-perlimports/
cpanm --installdeps .
export PERL5LIB="$PERL5LIB:/kohadevbox/koha/App-perlimports/lib"
find . \( -name "*.pl" -o -name "*.pm" \) -exec perl App-perlimports/script/perlimports --inplace-edit --no-preserve-unused --filename {} \;
The ideas of this patch are to:
* use EXPORT_OK instead of EXPORT
* perltidy the EXPORT_OK list
* remove '&' before the subroutine names
* remove some uneeded use statements
* explicitely import the subroutines we need within the controllers or
modules
Note that the private subroutines (starting with _) should not be
exported (and not used from outside of the module except from tests).
EXPORT vs EXPORT_OK (from
https://www.thegeekstuff.com/2010/06/perl-exporter-examples/)
"""
Export allows to export the functions and variables of modules to user’s namespace using the standard import method. This way, we don’t need to create the objects for the modules to access it’s members.
@EXPORT and @EXPORT_OK are the two main variables used during export operation.
@EXPORT contains list of symbols (subroutines and variables) of the module to be exported into the caller namespace.
@EXPORT_OK does export of symbols on demand basis.
"""
If this patch caused a conflict with a patch you wrote prior to its
push:
* Make sure you are not reintroducing a "use" statement that has been
removed
* "$subroutine" is not exported by the C4::$MODULE module
means that you need to add the subroutine to the @EXPORT_OK list
* Bareword "$subroutine" not allowed while "strict subs"
means that you didn't imported the subroutine from the module:
- use $MODULE qw( $subroutine list );
You can also use the fully qualified namespace: C4::$MODULE::$subroutine
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This alters the template check to use the presence of the plugins
arrayref rather than requiring a second call to check for
plugins_enabled.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Test Plan:
1) Install an EDI plugin
2) Browse to edi_accounts.pl, create or edit an account
3) Note the plugins pulldown is missing
4) Apply this patch
5) Restart all the things!
6) Reload the page
7) Note the pulldown is back!
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
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>
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>
Bug 9978 should have fixed them all, but some were missing.
We want all the license statements part of Koha to be identical, and
using the GPLv3 statement.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Imo it is much easier to do just "$a ? 1 : 0" than testing defined($a) etc.
in the additional loop.
Less code, more readable?
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Validate the input to the fields indicating account
functionality. The only valid values are 1 and 0
non-integer (or integers other than 0/1) are invalid
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Test plan:
Check use warnings; use strict doesn't exist and use Modern::Perl is written instead in the following files:
admin/admin-home.pl
admin/aqcontract.pl
admin/aqplan.pl
admin/auth_tag_structure.pl
admin/branch_transfer_limits.pl
admin/check_budget_parent.pl
admin/check_parent_total.pl
admin/checkmarc.pl
admin/classsources.pl
admin/clone-rules.pl
admin/didyoumean.pl
admin/edi_accounts.pl
admin/edi_ean_accounts.pl
admin/import_export_framework.pl
admin/item_circulation_alerts.pl
admin/marctagstructure.pl
admin/matching-rules.pl
admin/printers.pl
admin/smart-rules.pl
admin/systempreferences.pl
admin/transport-cost-matrix.pl
Signed-off-by: Jon Knight <J.P.Knight@lboro.ac.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Once again, after bug 16154 and bug 16259 we need to remove more
occurrence of CGi->param called in list context.
Refer to bug 15809 for more information.
Test plan:
Make sure you do not see the error on the modified scripts.
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>
To reproduce:
- In Staff client, go to Administration > EDI accounts
- Click "+ New account"
Result: Internal Server Error
Plack error log says:
Can't call method "param" on an undefined value at /home/marc/koha/admin/edi_accounts.pl line 157
To test:
-Apply patch
- Add an EDI account
- Edit an EDI account
- Delete an EDI account
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
It would be helpful if we could find a plugin based on some metadata
tag as returned by the plugin. This extends the use of GetPlugins that
already supports searching on method.
GetPlugins is used in: admin/edi_accounts.pl, plugins/plugins-home.pl and
tools/stage-marc-import.pl. The changes in these three scripts are
minimal and just related to parameter passing.
Test t/db_dependent/Plugins.t includes another test for GetPlugins. In this
regard a metadata tag has been added to t/Koha/Plugins/Test.pm.
NOTE: This adjustment will also be used in a redesign for bug 15545.
Test plan:
Run t/db_dependent/Plugins.t.
Enable pref UseKohaPlugins and config var enable_plugins.
Go to plugins-home.pl. Verify that it still lists your plugins.
Bonus: Check edi_accounts or stage-marc-import.pl if you have a working
plugin for that.
Signed-off-by: Liz Rea <liz@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Test plan:
1. Disable <enable_plugins> in koha-conf.xml (restart memcached if needed).
2. Open the EDI accounts admin page.
3. Notice incredible breakage.
4. Apply patch.
5. Reload page, should now display (and the "Plugin:" dropdown should
be hidden).
6. Re-enable <enable_plugins> (and the UseKohaPlugins syspref as
well).
7. Ensure that the "Plugin:" dropdown is once again displayed.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <bredan@bywatersolutions.com>
Koha's EDIFACT module works great for many European vendors,
but does not work will for US vendors, which have a much different
interpretation of 'standard'. In fact, each vendor may require
different arrangements of values in EDIFACT messages. It would be
impossible to encompass all these requirements within Koha's EDIFACT
module itself. Instead, we should allow the module to be pluggable, so
versions of the module can be developed for vendors that require EDIFACT
messages that don't conform to the standard set by Koha's EDIFACT
module.
Test Plan:
1) Apply this patch
2) Run updatedatabase
3) Enable Koha plugins
4) Install the Edifact stub plugin available at
https://github.com/bywatersolutions/koha-plugin-edifact-stub
5) Edit the EDI Vendor account, assign the plugin to a Vendor EDI account
6) Test EDI functionality ( ORDER, INVOICE ), there should be no errors
or changes to the EDIFACT message input or output
Signed-off-by: Jason DeShaw <JDeShaw@cityoffargo.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Add support for processing incoming Edifact Quotes, Invoices
and order responses and generating and transmission of
Edifact Orders.
Basic workflow is that an incoming quote generates an aquisition
basket in Koha, with each line corresponding to an order record
The user can then generate an edifact order from this (or another)
basket, which is transferred to the vendor's site
The supplier generates an invoice on despatch and this will
result in corresponding invoices being generated in Koha
The orderlines on the invoice are receipted automatically.
We also support order response messages. This may include
simple order acknowledgements, supplier reports/amendments
on availability. Cancellation messages cause the koha order
to be cancelled, other messages are recorded against the order
Which messages are to be supported/processed is specifiable on a
vendor by vendor basis via the admin screens
You can also specify auto order i.e. to generate orders from quotes
without user intervention - This reflects existing
workflows where most work is done on the suppliers website
then generating a dummy quote
Received messages are stored in the edifact_messages table
and the original can be viewed via the online
Database changes are in installer/data/mysql/atomicchanges/edifact.sql
Note new perl dependencies:
Net::SFTP:Foreign
Text::Unidecode
Signed-off-by: Paul Johnson <p.johnson@staffs.ac.uk>
Signed-off-by: Sally Healey <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
