This patch updates the database to include a record_table field in the
additional_field_values table and adds an index on that field.
This should facilitate more performant joins.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
# Failed test 'Correctly in search results page'
# at t/db_dependent/selenium/opac_holds.t line 88.
# 'Error: Can't use an undefined value as a HASH reference at /kohadevbox/koha/C4/XSLT.pm line 247'
# doesn't match '(?^u:Results of search for 'opac holds test place hold button')'
might be a conflict with bug 40943
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Failed with:
Failed test 'Context userenv set correctly with no flags'
at t/Koha/Script.t line 31.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
session_id is now part of userenv
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds sorting to lists of lists in the OPAC.
The mechanism used here for op=list is similar to the one
used in op=view, so it's stylistically and functionally
consistent with the rest of the Lists module in the OPAC.
Test plan:
0. Apply the patch and restart Plack (ie koha-plack --restart kohadev)
1. Create 20+ public lists and 20+ private lists for a particular user
you control (try to use names that range throughout the alphabet)
2. Using SQL, update the Modification date for at least 1 public
list and 1 private list
3. As an anonymous (ie not logged in user), go to
/cgi-bin/koha/opac-shelves.pl?op=list&public=0
4. Note you cannot see any lists
5. Go to http://localhost:8080/cgi-bin/koha/opac-shelves.pl?op=list&public=1
6, Note you can see public lists with a toolbar with the button "Sort"
below the alert "Log in to create a new list"
7. Using the "Sort" option, try out all the different sort options
for default, "List name", and "Modification date"
8. After sorting, try paging through the list of lists. You should
note that the sorting is retained through the paging.
9. prove t/db_dependent/Virtualshelves.t
10. Celebrate!
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch prevents span elements being filled with "undefined"
which are then shown to screen readers and print output.
Test plan:
0. Apply the patch
1. Enable the following system preference: OpacStarRatings (results,
details, and patron).
2. Check out an item to a user you can log in as (e.g. koha user)
3. Go to /cgi-bin/koha/opac-user.pl in the OPAC
4. Click "Print" on the toolbar above the summary table
5. Note that 5 occurrences of "undefined" do not appear next to the
title in the print output
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The AuthClient template plugin was causing 500 errors during database
upgrades when the identity_providers schema was out of sync. The plugin
tried to query the new 'auto_register_opac' column before the database
schema was updated, creating a chicken-egg problem.
This patch wraps the database query in Try::Tiny to handle schema
mismatches gracefully during upgrades, allowing the upgrade process
to continue without crashing the authentication interface.
Test plan:
1. On main, apply all bug 37711 patches BUT THIS ONE
2. Simulate an upgrade by:
* Edit Koha.pm so it points to the next version
* Move the atomicupdate file to the right number in db_revs
3. Restart everything:
$ ktd --shell
k$ restart_all
4. Access http://kohadev-intra.localhost
=> FAIL: You get a 500! With a stack trace!
5. Apply this patch
6. Repeat 3 and 4
=> SUCCESS: No 500 error, redirects to installer
7. Proceed with the upgrade:
=> SUCCESS: It works as it should
8. Run tests:
k$ prove -v t/db_dependent/Template/Plugin/AuthClient.t
=> SUCCESS: All tests pass
9. Sign off :-D
Signed-off-by: Tomás Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adapts the `Identity provider domains` CRUD page to handle
the new configuration options.
To test:
1. Have an IdP with some domains set. Make sure there's at least one
domain with auto-register enabled and one with it disabled.
2. Apply this patches
3. Run:
$ ktd --shell
k$ updatedatabase
=> SUCCESS: Updates successfully
4. Run:
k$ yarn build
5. Refresh the IdP domains page
=> SUCCESS: The domains table shows both OPAC and staff auto-register
options.
=> SUCCESS: The staff auto-register is disabled for both domains
=> SUCCESS: The OPAC auto-register matches what was set for each domain
regarding auto-register (remember that before this patchset,
auto-register only works for the OPAC).
6. Play with editing/adding/removing domain configurations
=> SUCCESS: Things work as expected, values are persisted on the DB
correctly.
7. Sign off :-D
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Before this patches, only OPAC auto-registration at login using
OAuth2/OIDC IdPs was allowed.
This patch makes the staff interface to be able to auto-register new
users.
On doing it, I had to track down the possible values for the `interface`
parameter in the case of the staff interface.
Koha::Template::Plugin::AuthClient uses 'staff' internally so I sticked
with it. The whole area needs more param validation and exceptions to
avoid mistakes for not knowing the valid values.
I added some safeguards on the Koha::REST::Plugin::Auth::IdP helpers.
They get tested on the added tests.
To test:
1. Apply this patch
2. Run:
$ prove t/db_dependent/Koha/REST/Plugin/Auth/IdP.t
=> SUCCESS: Tests pass!
3. Have a valid OAuth...
4. Enable Staff auto-register
5. Login with an external IdP on the staff interface
=> SUCCESS: It gets registered!
Note: it will probably lack permissions to access the staff interface,
but you can check on the DB it got registered.
6. Sign off :-D
Sponsored-by: ByWater Solutions
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch makes the API representation of the identity providers
domains match the new metadata.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We should not log/leak session_id!
Failed test 'Context set from userenv + interface'
at t/db_dependent/Koha/BackgroundJob.t line 132.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
Looks like you failed 1 test of 10.
Failed test 'enqueue() tests'
at t/db_dependent/Koha/BackgroundJob.t line 135.
Failed test 'Userenv set from job context on process'
at t/db_dependent/Koha/BackgroundJob.t line 240.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
Looks like you failed 1 test of 5.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Failed with:
at t/Koha/Script_cron.t line 28.
Structures begin differing at:
$got->{session_id} = undef
$expected->{session_id} = Does not exist
session_id is now part of userenv
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
We need to mock userenv
ERROR: Plugin dateaccessioned.pl: Can't use an undefined value as a HASH reference at /kohadevbox/koha/cataloguing/value_builder/dateaccessioned.pl line 30.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
0. APPLY PATCH, restart_all
1. Find or create a record that has some MARC fields that don't show up by default in the record display. ( I tested using a 538$a )
2. Go to Tools and you should see a new link for 'Record display customizations'.
3. From Record display customizations click 'New Entry'
4. Choose a display location, the choices should be StaffResultsPage, StaffDetailPage, OPACResultsPage, and OPACDetailPage
5. Add the following to the entry:
[% IF record.subfield('538' , 'a') %]
<span class="results_summary test1">
<span class="label">The 538a: </span>
[% record.subfield('538' , 'a') %]
</span>
[% END %]
6. Go to the record from step 1, you should see the 538$a labeled as 'The 538a:' with the appropriate data in it.
7. This should display in the appropriate location depending on if you chose StaffResultsPage, StaffDetailPage, OPACResultsPage, or OPACDetailPage. Check each of the locations.
8. Make a new, or edit existing, Record display customization and mark the 'Library:' field for a specific branch. Make sure that the Record display customization only shows up when you are logged in at that branch.
9. Install a new language pack, I tested with es-ES.
10. Make a new, or edit existing, Record display customization and fill out the language specific tab. Make sure the Record display customization shows correctly with the language you chose.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Anneli Österman <anneli.osterman@koha-suomi.fi>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This enhancement will amend the automatic_renewals.pl script to only print a warning about the EnhancedMessagingPreferences system preference being disabled if the script was run with verbose.
To test:
1. Disable EnhancedMessagingPreferences
2. Run misc/cronjobs/automatic_renewals.pl
3. Notice the warning is printed
4. Apply the patch and restart services
5. Run misc/cronjobs/automatic_renewals.pl and notice the warning is not printed
6. Run misc/cronjobs/automatic_renewals.pl --verbose and notice the warning is printed
7. Enable EnhancedMessagingPreferences
8. Run misc/cronjobs/automatic_renewals.pl and notice the warning is not printed
Sponsored-by: Catalyst IT
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
1) Apply patch and yarn js:build
2) Navigate to a vendor and add some contacts
3) View the vendor record
4) The contacts table should now be at the bottom of the page and the full width of the screen
5) The Ordering information section should be at the top right of the screen
Signed-off-by: Michaela <michaela.sieber@kit.edu>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In MARC bibliographic framework page, add a direct link to items tag (952 in MARC21 and 995 in UNIMARC) can be very useful.
Currently one needs to search for the tag, then click on actions, then click on "View subfields".
Test plan :
1) Go to Administration > MARC bibliographic framework
2) View any framework MARC structure
3) You see in tools bar new button "View items tag (952)"
4) Click on it, you see this tag subfields
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates the plugin wrapper to include the reports menu and have the breadcrumbs list reports instead of admin or tools when method="report"
To Test:
1. Install the Kitchen Sink Plugin
2. Navigate to Reports->Report plugins->Run Report.
3. Observe the admin menu shows
4. Apply the patch
5. Repeat step 2
6. Observe the report menu shows and the breadcrumbs are for the report module.
7. Check that the tools and configuration show the appropriate tool/admin context.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Updates to the search forms and labels:
- Use sentence case for the Z39.50/SRU search form label
- Update title text for the advanced search link
- Update the title for the advanced search pop-up window to
"Advanced Z39.50/SRU search"
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The advanced cataloging editor has a Z39.50/SRU search form
included on the page, but it's just labeled "Search," so it's
not at all clear what it's for.
Test plan:
1. Enable and go to advanced cataloging editor.
2. Note that the Z39.50/SRU search form is just labeled
"Search".
3. Apply patch, reload page.
4. Note that it's now labeled "Z39.50/SRU search".
5. Note that the advanced search pop-up window is now
labelled "Advanced Z39.50/SRU search".
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In bug 40587 we renamed a variable from $b to $basketno. After rebasing,
the auto-orders blocking code had a bug where it referenced an undefined
variable $b instead of $basketno when checking for PO number conflicts.
This caused warnings: "Use of uninitialized value $Koha::EDI::b in exists"
This patch:
- Renames $b to $basketno throughout the conflict checking code
- Updates test plan from 7 to 8 to match actual subtest count
Test plan:
1. Run prove t/db_dependent/Koha/EDI.t
2. Verify all tests pass without warnings
3. Confirm auto-orders blocking works correctly for duplicate PO numbers
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
With the move to Koha::File::Transports we need to update the tests
introduced in this patchset to match the others by generating a 'local'
transport and using that.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When po_is_basketname is enabled for a vendor, duplicate purchase order
numbers should prevent both automatic ordering (auto_orders) and manual
UI-triggered ordering to avoid conflicts with existing baskets.
This patch implements blocking functionality that:
1. Auto-orders blocking:
- Tracks baskets with PO number conflicts during quote processing
- Skips auto-ordering for baskets with duplicate PO numbers
- Logs clear warnings about blocked baskets
2. UI basket ordering blocking:
- Adds duplicate checking in create_edi_order function
- Returns detailed error information when conflicts detected
- Prevents EDI order creation for conflicting baskets
3. User-friendly error handling:
- Updates basket.pl to handle duplicate PO number errors
- Stays on basket page to display error messages
- Provides clear messaging about conflicts and resolution steps
4. Template messaging:
- Adds clear error message explaining duplicate PO conflicts
- Shows which existing basket uses the same PO number
- Guides users on next steps to resolve the issue
This ensures data integrity and prevents order processing conflicts
while providing clear feedback to users about duplicate PO number
issues.
Test plan:
1. Set up a vendor with EDI account and enable "po_is_basketname"
2. Create a basket with a specific name (e.g., "PO12345")
3. Process an EDIFACT quote that contains the same PO number:
- If auto_orders is enabled: verify the new basket is created but NOT automatically ordered
- Check the logs show "Auto-order blocked" message
4. For UI testing, create another basket manually with the same name
5. Try to generate EDI order via "Generate EDI order" button
6. Verify: Error message appears stating duplicate PO number conflict
7. Verify: Basket remains open (not closed)
8. Verify: Error message shows which existing basket uses the PO number
9. Test with po_is_basketname disabled: verify normal operation continues
10. Test with unique PO numbers: verify orders process normally
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When vendors are configured to use purchase order numbers for basket naming,
the purchase order number should be included in outgoing ORDER messages as
the document message number in the BGM segment for proper EDI workflow continuity.
According to EDIFACT specifications, the purchase order number from incoming
quote messages (RFF+ON segments) should be used as the document message number
in the BGM segment of outgoing ORDER messages, rather than as a separate RFF+ON
segment.
This follow-up ensures that:
1. Purchase order numbers from incoming QUOTE messages are preserved
2. The same purchase order numbers are sent back in ORDER messages via BGM segment
3. Vendors receive the reference numbers they expect for order processing in the
correct format.
Implementation:
- Added get_purchase_order_number() method to extract PO number from basket name
when vendor is configured with 'po_is_basketname'
- Modified beginning_of_message() to accept purchase order number parameter
- Uses purchase order number in BGM segment when available, falls back to basketno
- Added comprehensive tests for purchase order number handling in ORDER messages
Test Plan:
1. Apply patches
2. Configure a vendor EDI account with "Basket name source" = "Purchase order number"
3. Process a QUOTE message containing RFF+ON segment
4. Verify basket is created with purchase order number as name
5. Generate ORDER message from the basket
6. Verify ORDER message contains purchase order number in BGM segment
7. Run tests: prove t/db_dependent/Koha/Edifact/Order.t
This completes the round-trip EDI workflow for purchase order number handling
according to EDIFACT standards: Quote RFF+ON → Basket Name → Order BGM
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When a basket is created from an EDI quote with the vendor EDI account configured
to use purchase order numbers, the basket name should be protected from changes
to maintain the integrity of the purchase order number reference.
This patch:
- Makes the basket name field read-only in the UI when the basket was created
from EDI with purchase order number setting
- Adds explanatory text when the field is protected
- Implements server-side protection to prevent basket name changes even if
the UI is bypassed
- Preserves the original purchase order number derived name
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When processing EDI quotes with purchase order numbers, validate that the
purchase order number is unique for the vendor to prevent operational
confusion. The validation:
- Checks for existing baskets with the same purchase order number and vendor
- Includes both open and closed baskets in the uniqueness check
- Logs an error with the raw RFF+ON segment and details to the edifact_errors table
- Continues processing (non-blocking) to prevent data loss
- Provides system log warnings for monitoring
The error logging includes:
- Section: Raw RFF+ON segment (e.g., "RFF+ON:orders 23/1")
- Details: Clear description of the duplicate purchase order number issue
This ensures administrators can identify and resolve duplicate purchase order
numbers while maintaining system functionality and audit trails.
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This enhancement allows libraries to configure vendors to use the buyer's
purchase order number (from RFF+ON segments) as the basket name instead of
the EDIFACT filename, improving searchability and reference tracking.
Backend Changes:
- Added purchase_order_number() method to Koha::Edifact::Message to extract
RFF+ON segments from message-level data (before first LIN segment)
- Modified process_quote() in Koha::EDI to use purchase order number for
basket naming when configured, with fallback to filename
Frontend Changes:
- Updated admin/edi_accounts.pl to handle po_is_basketname parameter
- Added "Use purhase order numbers" option to EDI accounts template
Test Plan:
1. Apply patches and run database update
2. Go to Administration > Acquisitions > EDI accounts
3. Create or edit a vendor EDI account
4. Verify "Use purchase order numbers" option appears
5. Enable "Use purchase order numbers" and save
6. Process an EDIFACT quote file that contains RFF+ON segments
7. Verify the created basket name uses the purchase order number instead of filename
8. Process a quote file without RFF+ON segments
9. Verify the basket name falls back to the filename
10. Test with "Use purchase order numbers" disabled
11. Verify basket names use filenames regardless of RFF+ON presence
12. Run tests: prove t/Edifact.t t/db_dependent/Koha/EDI.t
The feature is optional and backward compatible - existing behavior is
unchanged unless explicitly configured.
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a new boolean field 'po_is_basketname' to the vendor_edi_accounts
table to allow configuration of how basket names are used in EDIFACT.
Changes:
- Added atomicupdate for existing installations
- Updated kohastructure.sql for new installations
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds tests for:
1. RFF+ON (Purchase Order Number) segment parsing in EDIFACT messages
2. Vendor configuration for basket naming preferences
3. Basket naming logic in QUOTE processing
Test coverage includes:
- Message-level RFF+ON segment extraction
- Validation that RFF+ON processing stops at LIN segments
- Multiple RFF segment handling
- Database field storage and constraints
- Basket naming configuration logic
- Fallback behavior when purchase order number unavailable
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Sponsored-by: Westminster City Council <https://www.westminster.gov.uk/>
Sponsored-by: Royal Borough of Kensington and Chelsea <https://www.rbkc.gov.uk/>
Sponsored-by: OpenFifth <https://openfifth.co.uk/>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
The envelope level of EDIFACT is called an 'Interchange'. This patch
updates our UI terminology to match the official protocol terminology as
what we're actually displaying here is the Interchange file that
contains the related messages for the Basket. The interchange file will
often contain other messages of the same type that came through at the
same time of the this basket generation.
Sponsored-by: Open Fifth <https://openfith.co.uk>
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch extends the EDIFACT message display functionality from the invoice page
to the basket page, providing comprehensive access to EDIFACT messages and error
reporting.
Features added:
- Toolbar buttons for viewing EDIFACT messages (quote/order)
- Smart button display: single button for one message type, dropdown for multiple
- EDIFACT parsing errors section with inline error display
- Errors grouped by message type with detailed information
- Conditional display: only shows when relevant data exists
Changes:
- acqui/basket.pl: Added EDIFACT message and error collection logic
- basket.tt: Added toolbar buttons and parsing errors section
- Uses existing modal system for raw message display
Sponsored-by: Open Fifth <https://openfith.co.uk>
Signed-off-by: Hannah Dunne-Howrie <hdunne-howrie@westminster.gov.uk>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch provides a link in the left hand menu so that from a vendor record you can access ERM agreements and licenses relevant to that vendor
Test plan:
1) Apply patch and reset_all
2) Navigate to ERM and create some agreements and licenses that link to a vendor and some that don't
3) Navigate to a vendor record
4) There should be links in the left hand menu for agreements and licenses
5) Click on these and you should be taken to ERM and see a filtered table based on that vendor
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This clears qa warnings.
Test plan:
Read the POD.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT] Inline tidy. Moved set_userenv_from_session before POD of next sub.
Signed-off-by: David Cook <dcook@prosentient.com.au>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>