When adding a document that does not use 010d as price document, but 071d, the price is not imported from koha since it only checks 010d and 345d.
To reproduce:
1 - Create a Koha item, make sure there is neither 010d or 345d
2 - Add a 071d and fill a price
3 - Export the item as marcxml
4 - If you do not have one: in acquisition, create a vendor, a basket associated to this vendor, and a line associated to this vendor
5 - Add a line to any open basket, select: import "from a new file" and
select the exported marcxml -> The price in 071 is not imported
6 - Apply patch
7 - Repeat 5 -> the price is properly imported
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1: have patrons with self_check, self_checkin_module, and self_checkout_module permissions
2: observe that these patrons don't get icons by their names in the patroninfo sidebar
3: apply patch, restart_all
4: reload your patrons, see they now have icons for self checkout and/or self check-in
Signed-off-by: Eric Garcia <cubingguy714@gmail.com>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
[1] This prevents a warn 'Violation of unique constraint in Letter'
from TestBuilder if the notice already exists.
[2] The about warn should no longer say that password changes will
fail but only warn about a missing notification.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Playing with the about page, I noticed prior tests in the codebase fail
if the letter doesn't exist.
This patch fixes that.
To test:
1. With a fresh KTD run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Patron.t
=> SUCCESS: Tests pass!
2. Delete the existing notices:
k$ koha-mysql kohadev
> DELETE FROM letter WHERE code="PASSWORD_CHANGE"; \q
3. Repeat 1
=> FAIL: Tests fail! Current tests print a warn (Test::NoWarning)
doesn't like this
4. Apply this patch
5. Repeat 1
=> SUCCESS: Tests now pass. The test creates its own notice.
6. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch adds a check in about.pl for when `NotifyPasswordChange` is
enabled but no notices are present on the system.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When NotifyPasswordChange is enabled and GetPreparedLetter fails to find
a PASSWORD_CHANGE letter template, the set_password method was returning
early with undef, preventing the password from being changed.
This fixes the issue by:
1. Removing the 'or return;' statement after GetPreparedLetter
2. Wrapping the letter processing in an if block to handle missing templates
3. Ensuring password change continues regardless of notification success
The password change should not fail just because the notification cannot
be sent. The notification is a nice-to-have feature, but the core
functionality (changing the password) should always work.
Test plan:
1. Apply the tests patch
2. Run:
$ ktd --shell
k$ prove t/db_dependent/Koha/Patron.t
=> FAIL: Tests fail!
3. Apply this patch
4. Repeat 2
=> SUCCESS: Tests pass!
5. Verify that when the letter template exists, notifications are still sent
6. Verify that when NotifyPasswordChange is disabled, password changes work
7. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: David Flater <flaterdavid@gmail.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When NotifyPasswordChange is enabled and a patron has a valid email address,
but there is no PASSWORD_CHANGE letter template, the set_password method
fails silently and returns undef instead of changing the password.
This adds comprehensive regression tests to demonstrate the bug:
1. Bug condition: Missing PASSWORD_CHANGE letter template causes password
change to fail and method returns undef
2. Control test: Password change works when NotifyPasswordChange is disabled
3. Control test: Password change works when PASSWORD_CHANGE letter exists
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Check out some items to a patron so they have a circulation history,
the check in some of those items..
2. Look at the patron's "Circulation history" table. There are four
possible background colors for each row: #ffffff, #f3f4f4, #F9FAE0,
and #FFFFCC.
3. Apply the patch and reload the page.
4. An orange/gold badge will appear under the "Return date" column of
the table for items that have been checked out, and there will no
longer be alternating, pale yellow rows.
Sponsored-by: Athens County Public Libraries
Signed-off-by: Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This patch updates the vendor detail view in order to make some menu
items translatable..
To test, apply the patch and run 'yarn build'. Test that the correct
strings are translatable. In this example I'm testing fr-FR:
- Update a translation:
> gulp po:update
> cd misc/translator
> perl translate update fr-FR
- Open the corresponding .po file for the strings pulled from
JavaScript e.g. misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from vue/components/Vendors/VendorShow.vue for
translation, e.g.:
#: koha-tmpl/intranet-tmpl/prog/js/vue/components/Vendors/VendorShow.vue:12
#, fuzzy
msgid "Basket"
msgstr "Paniers"
- Lines 12, 25, and 35 of VendorShow.vue have been modified.
- Delete the line "#, fuzzy"
- Edit the "msgstr" string if ncessary, however you want (it's just for
testing)
- Install the updated translation:
> perl translate install fr-FR
- Go to Acquisitions -> Vendors -> Vendor details.
- Switch to your updated translation.
- Confirm that the menu items under "New" are translated correctly.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Flater <flaterdavid@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When a calendar widget has been initiated as a date range selector (as
it is when creating a new booking), the selected dates are added to the
input field as "0000-00-00 to 0000-00-00". This "to" needs to be
translatable.
To test, apply the patch and test that the correct strings are
translatable. In this example I'm testing fr-FR:
- Update a translation:
> gulp po:update --lang fr-FR
> cd misc/translator
> perl translate update fr-FR
- Open the corresponding .po file for the strings pulled from
JavaScript e.g. misc/translator/po/fr-FR-messages-js.po
- Locate strings pulled from intranet-tmpl/prog/js/calendar.js for
translation, e.g.:
#: koha-tmpl/intranet-tmpl/prog/js/calendar.js:144
msgctxt "As in, from date1 to date2"
msgid "to"
msgstr ""
- Edit the "msgstr" string however you want (it's just for testing)
- Install the updated translation:
> perl translate install fr-FR
- In the staff interface, locate an bibliographic record with items and
change the "Bookable" option from the item details screen.
- Switch to your updated translation in the staff interface.
- Click the "Place booking" button.
- Fill out all the fields in the "Place booking" modal.
- After you select a date range, the "Booking dates" input field should
show your translated text.
Sponsored-by: Athens County Public Libraries
Signed-off-by: David Flater <flaterdavid@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
If the name is already in use, we just return.
It might make sense to have a console.debug() or similar to notify
developers that this is happening. Open for other opinions.
To test:
1) Apply the first patch which adds an additional hydrate call in main-container.inc
2) Go to acqui/acqui-home.pl
3) Verify that you see this error in the dev tool's console tab:
Uncaught (in promise) NotSupportedError: Failed to execute 'define' on 'CustomElementRegistry': the name "acquisitions-menu" has already been used with this registry
4) Apply the second patch
5) Run `yarn js:build` in ktd (assuming ktd).
6) Reload the page without cached assets (Ctrl/Cmd + Shift + R) and verify that the uncaught error is gone.
7) Sign off.
There's an additional problem here I (and probably you) noticed. But that's unrelated to this bug.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In Unimarc, the field for music incipit is 036. The test to display the music player is correctly on field 036 but the field displayed was 031 (which is valid for Marc21 but not for Unimac).
To test:
On a Koha Unimarc instance:
1- Set system preference "OPACPlayMusicalInscripts" to "Play" and "OPACShowMusicalInscripts" to "Show"
2- set the system preference OPACXSLTListsDisplay is set on koha-tmpl/opac-tmpl/bootstrap/{languagecode}/xslt/UNIMARCslim2OPACDetail.xsl
3- Update a framework of your choice to display subfield 036$2 $g $n $o $p in OPAC, intranet and editor (make sure the collapse checkbox is not checked)
4- Create a record with the previously modified framework, fill all mandatory fields and add a 036 field with at least subfield $2 $g $n $o $p, make sure you have no 031 field
example of a valid 036 field
036$2 pe
036$g G-2
036$n bB
036$o 3/4
036$p {8C'8C'}/4D4C'4F/2E
5- Go to the OPAC detail page for the record created (with interface in English)
6- check that the music player does not appear
7- apply the patch
8- Reload the OPAC detail page for the record created (sill with interface in English)
9- check that the music player appears and is working
Signed-off-by: Emmanuel Bétemps <e.betemps@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
In batch item modification, unchecking any column hides the previous column.
This is caused by new HTML in table header :
<span class="dt-column-title"></span><span class="dt-column-order"></span>
This patch fixed by adding ".dt-column-title" to function guess_nb_cols().
Test plan :
1) Go to batch item modification
2) In "Show/hide columns:" click on "Home library" column
=> Check correct column is hidden
3) Go to another batch item modification
=> Check column "Home library" is hidden (from cookie storage)
Signed-off-by: Emmi Takkinen <emmi.takkinen@koha-suomi.fi>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1 - confirm whether or not NewsLog is enabled on your system
2 - apply patch, updatedatabase, restart_all
3 - search system preferences, confirm you now have
AdditionalContentLog rather than NewsLog and that the new
description is accurate
4 - confitm AdditionalContentLog shows the value you previously had for
NewsLog
5 - go to Tools > Log Viewer
6 - confirm the checkbox here is labeled "Additional Content", that it
correctly reflects the syspref value, and that it links to the
syspref
7 - with AdditionalContentLog enabled, created/edit/delete news, HTML
customizations, and pages. confirm they log
8 - with AdditionalContentLog disabled, created/edit/delete news, HTML
customizations, and pages. confirm they don't log
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Pedro Amorim <pedro.amorim@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Running this update twice fails before this patch with:
ERROR: {UNKNOWN}: DBI Exception: DBD::mysql::db do failed: Data truncated for column 'checkprevcheckout' at row 3 at /kohadevbox/koha/C4/Installer.pm line 825
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
without this patch , when patrons are merged , you can't see the merge in the log viewer.
To test:
-Apply the patch
-Make sure you have "BorrowersLog" on in you System Preference
-Search patrons
-Check two ore more patrons
-Merge selected patrons
-Merge patrons
-Go to log viewer
- Make sure there is the line with the action : "Merge"
Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test :
- create an acquisition basket
- add at least one record
- close the basket (the "export as CSV" link is present)
- attach the basket to a basket group
- check that the "export as CSV" link, next to "reopen the basket" is
now gone.
- apply patch and reload the page (may need reload plack, cache, etc...)
- "export as CSV" link is now present even though the basket is
closed and it is attached to a basket group.
Signed-off-by: Sam Lau <samalau@gmail.com>
Signed-off-by: Dominique et Stephanie <stephanie.etallaz@univ-cotedazur.fr>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
To test:
1. Apply patch
2. reset_all (or start your testing environment in the first place)
3. Edit system preferences:
emailLibrarianWhenHoldIsPlaced - Enable
ReplyToDefault - enter a fake/test email address
ExpireReservesMaxPickupDelay - Allow
ExpireReservesAutoFill - Do
ExpireReservesAutoFillEmail - same email address as ReplyToDefault
4. Place two holds on the same bib for two different patrons, Patron A
and Patron B
5. Edit an item on that bib to set a call number (if it doesn't have one
already)
6. Check in that item to set Patron A's hold to waiting
7. Edit the expiration date on Patron A's hold to yesterday's date
To do this in KTD:
ktd --shell
koha-mysql kohadev
UPDATE reserves SET expirationdate = <yesterday's date>
WHERE borrowernumber = <Patron A's borrowernumber>;
8. Run misc/cronjobs/holds/cancel_expired_holds.pl to automatically
cancel the expired hold and fill the next one
9. Open koha-mysql again and run the following query to view the
generated notices:
SELECT subject, content FROM message_queue
WHERE to_address = '<the email address you set in step 3>';
--> Confirm that HOLDPLACED and HOLD_CHANGED notices were both generated
--> Confirm that all information has been filled in correctly for those
notices
Signed-off-by: Marion Durand <marion.durand@biblibre.com>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
- Add a new subscription to a serial record (with the option 'create an item record' selected)
- Receive several issues and create the linked items
- Return to the bibliographic record
- Select several items
- Click to 'Delete selected items'
- Tick the box 'delete serial issues linked to items' and confirm
- The items should be deleted correctly
- Back to subscription : the issues linked to items should no longer exist
Signed-off-by: Boubacar OUATTARA <boubacar.ouattara@biblibre.com>
Signed-off-by: Nathalie <nathalie.savarit@univ-amu.fr>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Test plan:
- Add a new subscription to a serial notice (with the option 'create an item record' selected)
- Receive one issue and create the linked item
- Return to the bibliographic record
- Edit item - Action - Delete
- Tick the box 'delete serial issues linked to item' and confirm
- The item should still be deleted correctly
- Back to subscription : the issue linked to the item doesn't exist any more
Signed-off-by: Boubacar OUATTARA <boubacar.ouattara@biblibre.com>
Signed-off-by: Nathalie <nathalie.savarit@univ-amu.fr>
Signed-off-by: Lisette Scheer <lisette@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
This new 'Mark completed' screen only shows when ILL_STATUS_ALIAS is not empty, i.e. Koha installations that are not using ILL_STATUS_ALIAS will not see any change in their workflow.
Backends that don't implement 'mark_completed' are inherently already making use of core 'mark_completed' and will automatically adopt this enhancement.
Backends that do implement their own mark_completed don't automatically adopt this enhancement and will not see any change in their workflow.
Test plan:
1) Enable ILLModule sys pref
2) Create a new ILL request:
<staff_url>/cgi-bin/koha/ill/ill-requests.pl?method=create&backend=Standard
3) Add a type, cardnumber and library. Click 'Create'.
4) You should now be on the manage request screen. Click 'Confirm' and 'Confirm request'.
5) You should be on the manage request screen again. Click 'Mark completed'. The request's status became 'Completed'.
6) Add at least one AV entry to ILL_STATUS_ALIAS av category, visit:
<staff_url>/cgi-bin/koha/admin/authorised_values.pl?op=add_form&category=ILL_STATUS_ALIAS
7) Add 'abc_code' to 'Authorized value' and 'abc_description' to 'Description'. Click 'Save'.
8) Repeat steps 2 to 5. Notice that when you 'Mark completed' now, a new screen is shown prompting for a status_alias.
9) Pick a status_alias and save. Notice the 'status' now shows the alias.
Sponsored-by: NHS England
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
prove /kohadevbox/koha/t/db_dependent/Koha/ILL/Requests.t
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When the AutoILLBackendPriority system preference is enabled, the form that was used is always the Standard form, regardless of which backend the request ends up on.
It only makes sense that when editing an ILL request's item metadata, the form shown is also the Standard form if AutoILLBackendPriority is in use.
Test plan, k-t-d, don't apply patch:
1) Enable ILLModule
2) Install an external backend, e.g. the libkey lending tool (IncDocs) backend plugin:
https://github.com/openfifth/koha-ill-libkey-lending-tool/releases/tag/v2.0.3
3) Restart plack
$ koha-plack --restart kohadev
4) Create a new IncDocs ILL request:
<staff_url>/cgi-bin/koha/ill/ill-requests.pl?method=create&backend=IncDocs
5) Add a DOI '123', a cardnumber '42' and any library. Click 'Make request'.
6) Enable AutoILLBackendPriority system preference by ticking 'IncDocs'. This is only done now to simplify the test plan, as creating an 'IncDocs' request using AutoILLBackendPriority requires credentials configuration.
7) Back on the 'Manage request' page for the request created in step 5, click 'Edit item metadata'. Notice the form shown is not the 'Standard' form (its the IncDocs one). Edit any of the metadata values, click 'Save'. Verify the new metadata is saved correctly.
8) Apply patch. Repeat 7). Notice the form shown is the 'Standard' form now. Edit any of the metadata values, click "Save". Verify the new medata is saved correctly.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
And list alphabetically on branchname
Signed-off by: Chris Rowlands <chris.rowlands6@nhs.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
And list alphabetically on branchname
Signed-off by: Chris Rowlands <chris.rowlands6@nhs.net>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Currently, advanced bibliographic records editor creates empty
subfields (or even empty fields) when no content is placed after
‡<code> (or, in case of control fields, after <tag>).
Test plan:
==========
1. Enable EnableAdvancedCatalogingEditor (have StripWhitespaceChars
set to "Don't strip" - the default setting).
2. Open a record in the advanced editor, create empty subfield and
empty fields, e.g.:
007
500 _ _ ‡a
246 3 1 ‡aAdditional title :‡b
3. Save the record. Go to bibliographic record Normal view and in
modal "MARC preview" notice that the fields / subfields you entered as
empty exist in the record with no data. This is wrong.
4. Apply the patch ; restart_all.
5. Repeat p. 2 and 3. Note that empty fields/subfields have not been
created.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Wojciech Baran <wojciech.baran@ignatianum.edu.pl>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
When no results are found, a warning:
[WARN] Argument "" isn't numeric in numeric gt (>) at /kohadevbox/koha/koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-results.tt line 76.
is generated in [plack-]opac-error.log
Test plan:
==========
1. In OPAC, perform a search for a random string of characters to get no
results.
2. Check plack-opac-error.log. You should see a warning as above.
3. Apply the patch ; restart_all.
4. Repeat the search. Check the log -- there should be no new warning.
Sponsored-by: Ignatianum University in Cracow
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Aude Charillon <aude.charillon@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
[WARN] Use of uninitialized value $view in exists at /kohadevbox/koha/Koha/Manual.pm line 346.
Signed-off-by: Aude Charillon <aude.charillon@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Aude Charillon <aude.charillon@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Query parameters break the manual mappings in vue modules.
If a url in a vue module contains query parameters the mapping for the manual fails and redirects to the homepage when 'Help' is clicked
To reproduce navigate to the agreements page in ERM and create at least one. On the list page, use the filters so that you have query parameters in the page URL. Click the 'Help' button - you just get the manual home page
Test plan:
Confirm that the original issue is fixed when this patch is applied.
Signed-off-by: Aude Charillon <aude.charillon@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Aude Charillon <aude.charillon@openfifth.co.uk>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Baptiste Wojtkowski
Andrew Fuerste Henry
Marcel de Rooy
Tomas Cohen Arazi
Owen Leonard
Paul Derscheid
Marion Durand
Fridolin Somers
Lucas Gass
Jonathan Druart
Martin Renvoize
Nick Clemens
Axel Amghar
Arthur Suzuki
Emily Lamancusa
Matt Blenkinsop
Pedro Amorim
Janusz Kaczmarek