Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch makes some tweaks to the style of the new information: We can
use the Bootstrap 5 "badge" class and "warning" style to get the
appearance we want.
This patch also adds output of the patron's restricted status if
present.
To test, apply the patch and rebuild the staff interface CSS. Perform a
patron search (from the checkout header search form for instance) and
confirm that a "restricted" badge appears alongside the branch and
expired badge.
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
1) Alter the 'Expiry date' of any patron.
2) Search for that patron on any search input that provides auto
complete results (e.g. top 'Search patrons' input)
3) Notice the expired patron has a 'expired' indication. Those who
aren't do not.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Add documentation for the new -si, --skip_indexing parameter
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Before the previous patch we were indexing with every AddAuthority/ModAuthority call and I assumed
we were also indexing during the commity, however, it appears we were not. This patch ensures we push
the record and ids into the arrays for indexing during commit.
Additionally I add a skip to next record on error, to match biblio behaviour.
I also correct a log referring to biblios during authority importing
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch adds a new optoin to skip indexing to bulkmarcimport.
It also fixes a bug where authorities were being indexed multiple times
during import.
To test:
1 - Apply patch
2 - Download the sample files on this bug
3 - Perform asearch engine search that should retrieve all records( 'a' in Zebra, '*' in ES)
4 - Note the total (435 in KTD)
5 - perl misc/migration_tools/bulkmarcimport.pl -b -v --file=bug_35466_b.mrc
6 - Search again, note increaed by 100
7 - perl misc/migration_tools/bulkmarcimport.pl -b -v --file=bug_35466_b.mrc --skip_indexing
8 - Search again, no increase
9 - perl misc/search_tools/rebuild_elasticsearch.pl -v
10 - Search again, increase, records were added but not initially indexed
11 - Browse to authorities and search as for biblios
12 - perl misc/migration_tools/bulkmarcimport.pl -a -v --file=bug_35466_a.mrc
13 - Search again, note increase
14 - perl misc/migration_tools/bulkmarcimport.pl -a -v --file=bug_35466_a.mrc --skip_indexing
15 - Search again, no increase
16 - perl misc/search_tools/rebuild_elasticsearch.pl -v
17 - Search again, increase, records were added but not initially indexed
18 - Sign off! Hi5!
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Thomas Klausner <domm@plix.at>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the log viewer interface so that users with the
correct permissions can click a module's "Log not enabled" icon to go
directly to the corresponding system preference for enabling the log.
To test, apply the patch and go to Tools -> Log viewer (must have
"view_system_logs" permission).
- You should see an icon next to each module for which logging is
disabled. Hovering over the icon should give a tooltip: "Log not
enabled."
- If you are logged in as a user with "manage_sysprefs" permission,
clicking the icon should take you directly to the system preference
for enabling or disabling that module's logs.
- If your user does not have "manage_sysprefs" permission the icon
should not be a link.
Sponsored-By: Athens County Public Libraries
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Laura_Escamilla <laura.escamilla@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Currently, if you have patron attributes and modify the values in a patron's account, the patron's updated_on date is not updated. This patch makes the "Updated on" change when a patron attribute is updated.
To test:
1. Create a patron attribute type
1.1. Go to Administration > Patron attribute types
1.2. Click New patron attribute
1.3. Fill out the code and description
1.4. Click Save
2. Edit a patron (normal)
2.1. Go to Patrons and find a patron account
2.2. Click Edit
2.3. Change a regular field (e.g. Middle name)
2.4. Click Save
--> Notice the "Updated on" date in the left column has been updated to now
3. Edit a patron attribute
3.1. In another patron account*, click Edit
3.2. Change the value of an attribute
3.3. Click Save
--> Notice the "Updated on" date did not change
4. Apply the patch
4.1 Repeat step 3.1, 3.2, 3.3
--> Notice the "Updated on" date has now changed
Signed-off-by: Esther <esther@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch was envisioned by Julian Maurice.
Test plan:
0. Apply the 1st patch (the revert)
1. Go to `misc/translator/po`
2. es-ES-messages-js.po
3. Mark "Edit" string as fuzzy (around line 48). It should look like:
```
msgid "Edit"
msgstr "Editar"
```
4. Edit ./intranet-main.tt and add the following lines at the bottom,
inside the `$(document).ready` block:
```javascript
console.log(_("Edit"));
console.log(__("Edit"));
```
5. Install the templates
k$ koha-translate --install es-ES --dev kohadev && restart_all
6. Enable *es-ES* by searching for `language` in the sysprefs and switch
to it for the staff interface.
7. Go to the Koha home page, open the browser console
=> FAIL: Notice that the second log in the console is displaying the
fuzzy string (i.e. is being translated when it shouldn't)
8. Apply this patch
9. Re-install the translated templates:
k$ koha-translate --update es-ES --dev kohadev && restart_all
10. Repeat 7
=> SUCCESS: With this patch applied both logs show the English version of the
string.
11. Remove the fuzzy flag on `es-ES-messages-js.po`
12. Repeat 9 and 10
=> SUCCESS: The results are similar to step 7, but in this case they are
expected as the string is not marked fuzzy.
13. Sign off :-D
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This reverts commit 4eb9816354.
Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com>
Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
In fact the system adds a previous value to the progress. As if the system keeps a previous value and adds the correct count of records in addition.
This patch removes the previously stored value.
To test:
1. Go to Cataloging > Stage records for import
2. Choose a file with bibliographic records and click Upload file
3. In "Look for existing records in catalog?" choose a record matching rule (e.g. ISBN)
4. Click Stage for import
5. Click View detail of the enqueued job
--> Progress show 2/1
6. Apply the patch
7. Repeat steps 1 to 4
8. Click View detail of the enqueued job
--> Progress show 1/1
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
qa script:
Commit title does not start with 'Bug XXXXX: ' - d1bebb34d7
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Fixed patch subject line
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch updates the field for the created by filter from
ui.item.borrowernumber to ui.item.patron_id
Test plan:
1. Add a vendor and a basket
2. Use advanced order search to search for created by 'koha'
3. Use the autofill dropdown to make the selection and click 'Search'
4. Your search returned no results.
5. Apply patch and repeat steps 2 and 3
6. Confirm the search returns the basket you created earlier
Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch disbles the "Submit" button when the barcode field is empty.
To test this patch:
Add the patch to your koha clone
Enable the "SelfCheckInModule".
Open the page and the "Submit" button should be disabled when the barcode field is empty.
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When the autoBarcode preference is set to « generated in the form 1, 2, 3 » and the maximum barcode is length 16 (ex 1000000000000000),
when adding orders to the basket,the numbers generated are in the hexadecimal form.
to reproduce:
1- Set the system preference autoBarcode to « generated in the form 1, 2, 3 »
2- Search for a biblio record
3- In the record details, click on New -> New item
4- fill the Barcode field to a number with length 16 (1000000000000000) and add the item
5- Create a suggestion
5-1- Go to Acquisitions and click on suggestions
5-2- Create a suggestion and accept it
6- Add a new order to a basket
6-1- Go to Acquisitions and find a vendor
6-2- Create a new Basket
6-3- on the Basket click on 'Add to basket' and select 'From a suggestion'
6-4- Add the order created on 5-2- to the basket
6-5- On the item form click on Add item
6-6- Select a Fund and save the order
7- In the orders table click on the record and check the item Barcode
---> the Barcode is in hexadecimal form
8- Cancel order and delete the catalog record
9- Apply the patch
10- Repeat step 6-4, 6-5, 6-6
11- Check the item Barcode
---> the Barcode is not in hexadecimal form
12- run prove t/db_dependent/Barcodes.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
When exporting a framework as csv, the exporter does not check the presence of double quote in the fields. Hence, if there is one double quote, the csv is broken.
TEST PLAN:
1 - Change a framework to add a field containing double quote in name
2 - Export it in csv
3 - Create a new framework
4 - Import the csv in the new framework -> every fields after the one
containing double quotes should be broke. Every other fields should have
no subfield
5 - APPLY PATCH
6 - Repeat 2-5 -> everything should be correctly exported
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
To test:
There should be no change in behavior, as this code is not referred to elsewhere in Koha. Make sure you can still do checkeckins and transfers.
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The inventory form has several issues with labels with a for attribute that
doesn't match the id of the input, so the label doesn't actually get linked
to anything.
Test plan:
1. Without the patch, go to Cataloging - Inventory
2. In the section for "Item location filters" click the label for "Shelving
location (items.location) is", which will focus the select menu, then
press the down arrow on the keyboard to see that it's focused by opening
the select menu.
3. Click in a blank spot to close the select menu, then click the label for
"Collection" and press the down arrow key, which will scroll the page
since the label didn't focus the menu, and repeat with "Call number
classification scheme" which also will scroll the page when you press
down arrow.
4. In the section for "Optional filters for inventory list or comparing
barcodes" click any of the labels below items.notforloan - clicking a
checkbox label should toggle whether the checkbox is checked, but it
will not
5. Apply patch, refresh page
6. Repeat steps 3 and 4, but this time you will get the proper behavior,
focusing the select menus and toggling the checkboxes
Sponsored-by: Chetco Community Public Library
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
It's named enqueued_date on the API side, not enqueued_on (which is the DB
column's name)
No behaviour change expected here.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This patch suggests to revert the previous attempt to fix this problem.
The date was using the client-side's tz and so the "last hour" was not
matching the one from the server.
With bug 37831 with simply need to pass a rfc3339-formatted date and the
filtering will be done as expected.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This reverts commit f5c8393480.
https://bugs.koha-community.org/show_bug.cgi?id=37905
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We do not want to apply "like" and do a "contains" search if a correctly
formatted date is passed (ie. starting with "YYYY-MM-DD HH:MM:SS")
It causes underlying problems if we add '%' characters to this string as
it will then become an invalid date.
There are several ways of dealing with this problem. This patch is
suggesting the easiest path: Apply an exact search (ie. do not add '%')
if the value appears to be a datetime.
Certainly not the best looking patch but it seems to be quite effective:
* no need to change the client
* no need to rework build_query_params, merge_q_params, attributes_from_api
We could (to confirm) pass the result set, but it seems a lot of additional processing
(that is done later already, in attributes_from_api)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
If we pass a datetime parameter we are adding "like" operator and % at
the beginning and ending of the attribute value.
For instance:
attributes=2024-09-16 10:11:12
attributes:{ like => '%2024-09-16 10:11:12%' }
We do not want to reach the fixup code and raise an exception.
However I don't think we should add the like for datetime attributes
actually. But can we modify this behaviour now?
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
We didn't take into account the server's timezone.
This does not feel right, we are not supposed to deal with time zone
outside of Koha::DateUtils.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
There are still different structures we won't handle properly.
This patch adds conditionals to prevent failures or warnings.
Should be done, but later.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Previously we only adjusted the attributes that were passed directly,
not the ones in 'q' (which is the recommended way now)
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
The test is not catching missing op in forms that are not the first POST
form of the template.
Found when fixing the test for bug 37309. It was not catching the
missing op in the second form.
Signed-off-by: Phil Ringnalda <phil@chetcolibrary.org>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
xt/find-missing-op-in-forms.t wants to see name="op" value="cud-..." in any
form with method="post", but opac-illrequests.tt inserts its op input by
passing around whole and unpack and repacking whole.keys which includes
the op. We just need to tell the test that it really exists.
At first, I thought of this approach as a joke, faking out the test, but
when I tried to be more responsible and put a whole <input type="hidden" etc.
in the comment, I realized that would be more likely to confuse someone
who thought that was uncommented and that they were making real changes than
it would be to future-proof against changes in the test's approach.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Pedro Amorim <pedro.amorim@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
members/cancel-charge.pl will take either a POST or a GET, and as long as the
accountline_id it is passed can be cancelled, will cancel it. That means any
link you click anywhere while logged in to Koha might cancel a charge. It also
takes a borrowernumber which isn't used for the cancelling, only to determine
what account to show after a charge is cancelled, letting a malicious link
show an account other than the one whose charge was just cancelled.
Test plan:
1. Without the patch, Circulation - Checkout - search for the 'koha' patron
you log in as
2. Accounting - Create manual invoice - Make it a Manual fee of 100.00 and
Save
3. Pretending it's a well-disguised link in a spear-phishing email, load
http://localhost:8081/cgi-bin/koha/members/cancel-charge.pl?borrowernumber=5&accountlines_id=1
4. You are now looking at charges for the patron Acosta, Edna rather than for
the patron koha, but if you look at the patron koha, its 100.00 charge
has been cancelled.
5. Apply patch and reset_all (or if you don't, you'll have to manually adjust
the link to reflect the charge being accountlines_id 3 rather than 1)
6. Circulation - Checkout - search for the 'koha' patron you log in as
7. Accounting - Create manual invoice - Make it a Manual fee of 100.00 and
Save
8. Click the link http://localhost:8081/cgi-bin/koha/members/cancel-charge.pl?borrowernumber=5&accountlines_id=1
9. You got a 403 because you didn't pass the op cud-cancel, but if you did
pass that op, you would also get a 403 for having a cud- op in a GET (and
if you POST, you won't have a csrf_token)
10. Checkout - search for koha - Accounting - Cancel charge
11. Having done it the right way, you're now on koha's list of transactions,
where you can see you just cancelled it
Sponsored-by: Chetco Community Public Library
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This code could appear several time as we include it in modals
Test plan:
Go on http://localhost:8081/cgi-bin/koha/suggestion/suggestion.pl
Open the console
Notice that without this patch you see a JS error
Uncaught SyntaxError: redeclaration of const av_bsort1
With this patch applied the error is gone.
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Patron may be undefined. So the test may crash.
Also there is an issue with operator precedence.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Test plan:
Run t/db_dependent/Koha/Patron.t
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
[SQUASHED IN QA]
These patches will alter the checks for a patron that prevent a category with
'can_be_guarantee' from being a guarantor. Two patrons in the same category should be
allowed to have a guarantee/guarantor relationship
The tests below assume you are using the KTD sample data. Update borrowernumbers if not.
To test:
0 - Apply tests patch
1 - Set the 'Patron' category as 'Can be a guarantee'
2 - Add a relationship between two patrons of the same category
This is restricted from the staff interface
perl -e 'use Koha::Patrons; my $p = Koha::Patrons->find(5)->add_guarantor({ guarantor_id => 23, relationship => 'father'});'
3 - Note there is no warning or exception. This should be allowed.
4 - Checkout an item to Edna (borrowernumber 5)
5 - Set 'TrackLastPatronActivityTriggers' to 'Checking in an item'
6 - Try to check the item in, KABOOM
7 - Set 'TrackLastPatronActivityTriggers' to 'Checking out an item'
8 - Try to issue an item to Enda, KABOOM
9 - prove -v t/db_dependent/Koha/Patron.t, fail
10 - Apply second patch
11 - prove -v t/db_dependent/Koha/Patron.t, one more test passes, but then fail
12 - Apply third patch
13 - prove -v t/db_dependent/Koha/Patron.t, pass!
14 - restart_all
15 - Checkout to Enda, OK!
16 - Checkin from Edna, OK!
17 - Find two more patrons in the category and attempt to link them
18 - 'Guarantor cannot be a guarantee'
19 - Apply fourth patch
20 - You can add a guarantor from the same category in interface
21 - Try to add a guarantor to the guarantor assigned in 20
22 - Confirm you cannot add a guarantor - "Guarantor cannot be a guarantee"
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: Fix patron updates
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: Fix patron creation
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: Fix memberentry.pl
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Signed-off-by: Baptiste Wojtkowski <baptiste.wojtkowski@biblibre.com>
Bug 37892: (follow-up) Fix patron creation
This patch fixes the 22. of the test plan (22 - Confirm you cannot add a guarantor - "Guarantor cannot be a guarantee"
)
Signed-off-by: Olivier V <olivier.vezina@inLibro.com>
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Bug 37892: (follow-up) Fix patron creation
TEST PLAN:
1 - Do the 22 parts of the test plan
2 - Add a guarantor to one patron not selected before (let's say A is
the guarantee, B the guarantor)
3 - Try and add a guarantor to B -> you will success
4 - Remove B's guarantor
5 - Apply this patch
6 - Repeat 3 -> you will not be able to
Signed-off-by: Brendan Lawlor <blawlor@clamsnet.org>
Bug 37892: (follow-up) Tidyness
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
[EDIT]
Renamed a subtest to patron creation tests in Patron.t.
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Lucas Gass
Owen Leonard
Pedro Amorim
Thomas Klausner
Nick Clemens
Laura_Escamilla
Kyle M Hall
Hammat Wele
Tomas Cohen Arazi
Hinemoea Viault
Brendan Lawlor
Bo Gustavsson
Baptiste Wojtkowski
Andrew Fuerste Henry
Phil Ringnalda
Jonathan Druart
Katrin Fischer
Marcel de Rooy
Baptiste Wojtkowski