Do not show the empty dropdown with no options if borrowerRelationship
is disabled (empty) in the syspref.
To reproduce:
1) Go to system preferences and disable borrowerRelationship.
2) Create a new patron or modify the existing one.
3) Under "Guarantor Information" click on "Search to add" button.
After performing the search, select different patron to act as
guarantor.
4) Observe that there's empty dropdown for the relation type.
5) Apply the patch.
6) Repeat steps above.
7) Observe that dropdown is no longer there.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When borrowerRelationship is empty in system preferences, Relationship
dropdown is not required and we accept empty value.
Also fixes bug that didn't let you to pick empty value even when you
specified that it should be possible in system preferences but in the
end of the string (i.e. "|father|mother" worked,
but "father|mother|" don't).
To reproduce (borrowerRelationship can be empty):
1) Go to system preferences and make borrowerRelationship empty.
2) Create a new patron who is assumed to have a guarantor or modify
the existing one.
3) Under "Guarantor Information" click on "Search to add" button.
After performing the search, select a user to act as guarantor. Try to save your changes.
4) Observe that relationship field is required in order to save but
you can't actually choose anything as it doesn't contain anything.
5) Apply the patch.
6) Repeat steps above.
7) Observe that it allows you to save the form now.
To reproduce (can't choose empty value bug):
1) Go to system preferences and set borrowerRelationship exactly
to "father|mother|".
2) Create a new patron who is assumed to have a guarantor or modify
the existing one.
3) Under "Guarantor Information" click on "Search to add" button.
After performing the search, select a user to act as guarantor.
4) Observe that there's no option to leave relationship field empty.
5) Apply the patch.
6) Repeat steps above.
7) Observe that it has empty option that you can choose and save
the form.
Mentored-by: Andrew Nugged <nugged@gmail.com>
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Do not split the config using comma.
From syspref description of borrowerRelationship preference:
> Guarantors can be the following of those they guarantee:
> (input multiple choices separated by |). Leave empty to deactivate.
As it doesn't mention comma at all, I removed ',' from split.
Of course if comma is actually a viable way to split separate choices,
I can obsolete this patch and append to the syspref description that it
also can be separated by comma.
Signed-off-by: Andrew Fuerste-Henry <andrew@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Run prove t/db_dependent/Members.t
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The patron deletion script misc/cronjobs/delete_patrons.pl uses C4::Member::GetBorrowersToExpunge() to get patrons that may be deleted.
This method filters patrons from a staff category.
I propose to also filter patrons having permission, so a staff member.
Some small libraries do not define a "staff" category and give permissions to regular patrons.
Test plan :
1) Create a patron on adult type category with expiry date in the past and permission to access staff interface
2) Without patch
3) Run delete script : ./src/misc/cronjobs/delete_patrons.pl -v --expired_before='$(date -I)'
4) You see the patron will be deleted
5) Apply patch
6) Run delete script : ./src/misc/cronjobs/delete_patrons.pl -v --expired_before='$(date -I)'
7) You dont see the patron
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds an option to the Point of sale jEditable configuration
to explicitly set the title attribute to "Click to edit." This will
allow the string to be picked up for translation.
To test, apply the patch and test that the correct string is
translated. In this example I'm testing fr-FR:
- Update a translation:
> cd misc/translator
> perl translate update fr-FR
The "Click to edit" string should already have been translated, so
it's not necessary to update the .po file.
- Install the updated translation:
> perl translate install fr-FR
In the staff interface, switch to the language you're testing and open
the point of sale page. Add some items for purchase. They should appear
in the "This sale" table. Hover your mouse over the values in the "Coût"
and "Quantité" columns. You should see the translated string, "Cliquer
pour modifier."
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch adds a min attribute to the form fields of the borrower
account page modals to prevent negative values being entered
inappropriately.
Test plan
1/ Trigger the refund modal from the borrower account page.
2/ Attempt to enter a negative value for the amount to refund and note
with the patch applied you face a validation error (without the patch,
upon submission of a negative value you will be faced with a server side
error)
3/ Trigger the discount modal from the borrower account page.
4/ Attempt to enter a negative value for the amount to discount and note
with the patch applied you face a validation error (without the patch,
upon submission of a negative value you will be faced with a server side
error)
5/ Signoff
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
On bug 27715 we restrict the order by dt params for security reasons.
However in some cases the param passed is "columnname" instead of
"table.columnname".
We should make sure the table is part of the sort fieldname.
Test plan:
Do a "normal" patron search (from the patrons home page) and another
patron search (guarantor for instance).
Sort by cardnumber, date of birth, expiration date, asc, desc and
confirm it works as expected.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch:
- Updates lanugage to be clearer 'ChargeFinesOnClosedDays' vs 'ChargeFinesOnCloseDay'
- Removes a stary warn
- Add an 'updated' counter and provides feedback in fines.pl
Test plan:
0 - Apply patches, updatedatabase
1 - set finesCalendar to 'ignore', ChargeFinesOnClosedDays to "Don't charge"
2 - Checkout an item due yesterday
3 - Ensure circ rules have a fine amount and interval set
4 - Make today a holiday
5 - perl misc/cronjobs/fines.pl -v
6 - 0 updated
7 - ChargeFinesOnClosedDays to "Charge"
8 - perl misc/cronjobs/fines.pl -v
9 - 1 updated
10 - set fines calendar to 'use'
11 - perl misc/cronjobs/fines.pl -v
12 - 1 updated (NOTE: This is wrong maybe, but handle on another bug)
13 - set ChargeFinesOnClosedDays to "Don't charge"
14 - perl misc/cronjobs/fines.pl -v
12 - 0 updated
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Bug 27180 added a patch to not update fines on holidays if finesCalendar was set to ignore.
At least it's what it advertised, but not what it did.
It seems that we need to add a new pref to control the calculation of
fines on closed days to answer the different use cases.
Test plan:
With this patch applied you can run the fines.pl cronjob and play with
the new pref ChargeFinesOnCloseDay to generate fines on close days.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This reverts commit a26d529a2b.
Revert "Bug 27180: Update fines on holidays"
This reverts commit 80e1b4e66f.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
To test:
1- go to /cgi-bin/koha/circ/returns.pl, click Checkin settings to show options
2- it says "Remember due date ..."
3- apply patch, reload
4- it says "Remember return date ..."
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
When the ILL notices were added, a bad rebase got rid of the notice
description in both messaging-preference-form.inc and opac-messaging.tt
This patch restores that line:
1. Set AutoRenewalNotices to 'according to patron...'
2. Edit a patron category
=> FAIL: There's an 'Unknown' label for 'Auto renewal'
3. Look at a patron's messaging preferences
=> FAIL: There's an 'Unknown' label for 'Auto renewal'
4. Look at a patron's messaging preferences in OPAC
=> FAIL: There's an 'Unknown' label for 'Auto renewal'
5. Apply this patch
6. Repeat 2, 3, 4
=> SUCCESS: 'Auto renewal' is displayed as expected
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch enhances auto_renewals message, removes auto_renewals messaging preference when AutoRenewalNotices is not set to ‘preferences’ and uses that preference to send notices in automatic_renewals.pl script.
To test:
1. Apply patches
2. updatedatabase
3. make sure automatic renewals are allowed in circ rules, have a positive number of allowed renewals and a positive number for renewal period
4. Check AutoRenewalNotices preference
SUCCESS => AutoRenewalNotices has the value ‘cron’ (means that It keeps the usual behaviour)
5. Checkout two items for a patron, and set them as automatic renewal and set due date as your current yesterday
6. perl misc/cronjobs/automatic_renewals.pl -c -v
SUCCESS => items were renewed, but there is no message in message_queue table in mysql
7. Repeat step 5
8. perl misc/cronjobs/automatic_renewals.pl -c -s -v
SUCCESS => items were renewed, and there is one message per item in message_queue table in mysql
9. Change AutoRenewalNotices to ‘never’
10. Repeat step 5
11. perl misc/cronjobs/automatic_renewals.pl -c -s -v
SUCCESS => items were renewed, but there is no message in message_queue table in mysql, even with the -s switch
12. Check any patron’s category, and any detail page in staff or OPAC interface, and in any of them you should find Auto Renewals messaging preference
13. Change AutoRenewalNotices to ‘preferences’
14. Repeat step 12, but this time all of them shows the Auto Renewals messaging preference.
15. Repeat step 5 with a patron that has no messaging preference setted
16. perl misc/cronjobs/automatic_renewals.pl -c -s -v
SUCCESS => items were renewed, but there is no message in message_queue table in mysql, because patron didn’t choose to receive messages
17. Grab a category and modify auto renewals messaging preferences, and save
18. Create a new patron from that category.
SUCCESS => created patron has the same messaging preference for auto renewals
19. Grab that patron and change auto renewals messaging preference to email but not digest
20. Repeat step 5 for that last patron.
21. perl misc/cronjobs/automatic_renewals.pl -c -v
SUCCESS => Items were renewed, and there is a message for each item in message_queue table in mysql.
22. Change auto renewals messaging preference from the same patron and set to email and digest.
23. Repeat step 5.
24. perl misc/cronjobs/automatic_renewals.pl -c -v
SUCCESS => items where renewed, and now there is only one message in message_queue table with the details of both renewed items.
25. Check that any changes to a patron’s auto renewals messaging preference in staff is reflected in OPAC, and the other way arround too.
26. Sign off
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds the "Auto renewals" messaging preference on intranet and OPAC, and adds digest feature to misc/cronjobs/automatic_renewals.pl script.
(Deprecated test plan. Please check the last patch)
To test:
1. apply patches
2. perl installer/data/mysql/updatedatabase.pl
3. make sure automatic renewals are allowed in circ rules, have a positive number of allowed renewals and a positive number for renewal period
4. go to patron categories in administration of staff interface and choose a category.
CHECK => in "Default messaging preferences for this patron category" has a "Auto renewals" row and has email and digest options checked
5. grab a patron and go to details page
CHECK => patron's messaging preferences has a "Auto renewals" row with email and digest options checked
6. some settings and save
7. go to opac with that same patron to "your messaging" option
CHECK => patron's messaging preferences has a "Auto renewals" row, and displays changes made in staff interface.
8. uncheck email and digest from "Auto renewals" row and save
9. check out an item for that patron, and set it as automatic renewal and set due date as your current yesterday
10. perl misc/cronjobs/automatic_renewals.pl -c --send-notices -v
SUCCESS => item was renewed, and in message_queue table there is no new message for the patron
11. update patrons messaging preferences and set email option of "Auto renewals" row as checked
12. repeat steps 9 and 10
SUCCESS => item was renewed, but in message_queue table there is a new message of type AUTO_RENEWALS
13. update patrons messaging preferences and set email and digest options of "Auto renewals" row as checked
14. repeat steps 9 and 10
CHECK => item was not renewed
15. run step 10 again, but add -d flag, like this:
perl misc/cronjobs/automatic_renewals.pl -c --send-notices -v -d
SUCCESS => item was renewed, and in message_queue table there is a new message of type AUTO_RENEWALS_DGST
16. Sign off
Signed-off-by: tgoat <tgoatley@gmail.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Marti Fuerst <mfuerst@hmcpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: tgoat <tgoatley@gmail.com>
Signed-off-by: Kelly McElligott <kelly@bywatersolutions.com>
Signed-off-by: Marti Fuerst <mfuerst@hmcpl.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Bug 18532: (QA follow-up) Atomicupdate syntax
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add a patron holds controller for the REST api and impliment the #list
methods.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Addd unit tests for the new patrons/{patron_id}/holds api route.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Add /api/v1/patrons/{patron_id}/holds route and holds object description
to the OpenAPI specification.
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch adds an ajax driven cashup summary modal to the library
registers summary page.
Test plan
1/ Enable UseCashRegisters in the system preferences
2/ Add at least one cash register to your library
3/ Make some payments of various types (Cash, Card) against the cash
register
4/ View the register transactions details page
5/ Make a refund against a payment
6/ Cashup
7/ View the cashup summary by clicking on the 'Summary' link on the
register page.
8/ Navigate to the 'libraries' summary page
9/ View the cashup summary by clicking on the 'Summary' link in the
registers table.
10/ Signoff
Signed-off-by: Sally <sally.healey@cheshiresharedservices.gov.uk>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
No longer exists and not used in this template
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>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch highlights a problem with the try/catch conditions in the
ad() controlled method. Tests are added, and the controller is fixed to
reflect the right behaviour.
To test:
1. Apply this patch
2. Run:
$ kshell
k$ prove t/db_dependent/api/v1/transfer_limits.t
=> SUCCESS: Tests pass! 409 is returned as appropriate!
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The current transfer limits editor works great for Koha instances with
small numbers of branches. However, for consortiums with dozens or even
hundreds of libraries, the editor does not work well or effectively.
We should provide an "advanced" editor displays all to/from library
combinations in a grid and allows them to be edited in a manner somewhat
similar to the transport cost matrix editor.
Test Plan:
1) Apply this patch
2) Browse to the transfer limits editor
3) Click the new "Switch to advanced editor" link
4) Select a collection code/item type to edit limits for
5) Test the "Check all" function
6) Test the "Uncheck all" function
7) Test the "Check" column function
8) Test the "Uncheck" column function
9) Test the "Check" row function
10) Test the "Uncheck" row function
11) Test individual checkboxes/table cells
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Lisette Scheer <lisettes@latahlibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
The various subpages of the label creator tool we're under the
'catalogue' permission. There is however a 'label_creator' subpermission
of tools which is more appropriate.
Test plan
1/ Setup a user with just the 'catelogue' permission (to enable logging
into the staff interface)
2/ With the patch applied you should not be able to access the following
pages (either via navigation in the UI or by typing them into the
browser address bar directly)
- /patroncards/add_user_search.pl
- /patroncards/edit-batch.pl
- /patroncards/edit-layout.pl
- /patroncards/edit-profile.pl
- /patroncards/edit-template.pl
- /patroncards/home.pl
- /patroncards/image-manage.pl
- /patroncards/manage.pl
- /patroncards/print.pl
3/ Signoff
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Same as the previous patch but for the password recovery feature.
Test plan:
1. Do not apply the patches
2. Set KohaAdminEmailAddress to an invalid email (root@localhost for
instance)
3. Use the password recovery feature
5. Boom (that must be fixed on a separate bug report)
6. Set KohaAdminEmailAddress to a valid email (root@example.org)
7. Use again the password recovery for a different user
8. Still Boom! (because it's processing the first invalid email)
9. Apply the patches, restart_all
10. Try again the password recovery
=> The email is sent!
Notice the change in DB, the first email is still there with status
"pending" and second email is sent!
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If the pref KohaAdminEmailAddress was not set correctly (invalid email)
and has been used to generate message, the message_queue table can contain
some messages that are not sent (pending) and will be processed each
time a new self-reg is done.
The PatronSelfRegistrationVerifyByEmail feature must send only the
notice we just generated, not the whole pending queue.
Test plan:
1. Do not apply the patches
2. Set KohaAdminEmailAddress to an invalid email (root@localhost for
instance)
3. Turn on PatronSelfRegistrationVerifyByEmail
4. Self-reg a patron
5. Boom (that must be fixed on a separate bug report)
6. Set KohaAdminEmailAddress to a valid email (root@example.org)
7. Self-reg a patron
8. Still Boom! (because it's processing the first invalid email)
9. Apply the patches, restart_all
10. Self-reg a patron
=> The email is sent!
Notice the change in DB, the first email is still there with status
"pending" and second email is sent!
QA: at step 10. TODO first email must be 'failed' (highlight in tests)
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
We could use C4::Letter::GetMessage, but the query in
_get_unsent_messages join on borrowers and return the branchcode.
To prevent any regressions it's preferable to not modify
SendQueuedMessages.
Ideally we obviously need a Koha methods to have better and clean code..
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
If we are searching on kw there is a leading colon at the beginning of
the generated query:
kw:foo becomes :foo
Note that it only happens when there is no other terms before.
Test plan:
0. Don't apply the patch
1. Search for kw:foo
2. Notice the error
Error: Unable to perform your search. Please try again.
and the logs say
Failed to parse query [(:foo*)]
3. Apply the patch
4. Repeat the search and notice that you know get:
"12 result(s) found for 'kw:foo'."
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
To keep the specificity of the rules we want to have apply to both the
biblio editor and also the authorities editor, we need to add the ID for
the authorities editor, rather than remove the ID for the biblio editor.
Also, the removal of the selectors for #authoritiestabs descendents was
regressing the display of authority record details, which is where that
plural authoritiestabs element lives.
Test plan:
1. With neither patch from this bug applied, Cataloging - New record -
Default framework.
2. Shrink and widen your browser window, noticing how the input fields
flex to remain the full width, keeping the controls to duplicate and
delete a subfield out directly to the right of the input.
3. Authorities - search for Perl (or any term that will match a record),
click the linked authority term to open the Authority detail display
4. Note how the field number, field description, and subfield descriptions
are all different colors, and subfield codes are on the same line as
the subfield contents.
5. Apply both patches from this bug.
6. Cataloging - New record - Default framework
7. Verify that the input fields still behave the same as you widen and
shrink your browser window
8. Authorities - New authority - Chronological Term
9. Verify that the input fields now behave like the ones in the biblio
editor, shrinking and widening to fill the width of the page, keeping
the controls to duplicate and delete subfields immediately to the
right of the field
10. Authorities - search for Perl, click the linked authority term to open
the Authority detail display
11. Verify that the tag number, field description and subfield descriptions
are still properly colored and subfield codes are still on the same
line as the subfield contents.
Signed-off-by: David Nind <david@davidnind.com>
Trivial fixup for a copy-paste failure, missed the y on
subfield_loop_mandator
Signed-off-by: Petro Vashchuk <stalkernoid@gmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
This patch changes the markup structure for the authorities
editor so that it better matches that of the basic bibliographic
record editor. This allows the authority-linking JavaScript to
correctly target fields on both pages.
To test, apply the patch and go to Authorities in the staff client.
- Create or edit an authority record.
- Switch to tab 5 and if necessary click one of the tag names (e.g.
"SEE ALSO FROM TRACING--PERSONAL NAME") to expand the subfields.
- Click the "..." plugin link next to subfield a ("Personal name" in
this example).
- In the popup window, search for an authority record.
- Click "Choose" next to one of the results.
- The popup window should close and the authority editor should contain
data from the record you chose, including a value in $9 and $a.
- Test with various records to confirm that data in other fields is
copied correctly, for instanct $d, dates associated with a name, $t
title of a work.
- Test other JavaScript-driven interactions in the editor:
- Duplicate repeatable tag
- Remove repeatable tag
- Empty tag
- Reorder sortable tags (e.g. multiple 500 tags)
- Reorder sortable subfields
- Duplicate repeatable subfield
- Remove repeatable subfield
- Empty repeatable subfield
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
https://bugs.koha-community.org/show_bug.cgi?id=22737
Signed-off-by: David Nind <david@davidnind.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
