This patch adds HTML comments to Template::Toolkit include files which
contain <script> tags so that it is clear where the embedded scripts can
be found in the code.
To test, apply the patch and view source on the following pages to
verify the presence of the comments:
Acquisitions home page:
- acquisitions-toolbar.inc
- validtor-strings.inc
- js_includes.inc
- format-price.inc
Acquisitions -> Add order from new record,
Acquisitions -> Receive order:
- additem.js.inc
Cataloging -> Add/Edit item:
- columns_settings.inc
- strings.inc
- select2.inc
- calendar.inc
- str/cataloging_additem.inc
Authorities home page:
- authorities_js.inc
Bibliographic detail page:
- catalog-strings.inc
Cataloging -> Advanced editor:
- cateditor-ui.inc
- cateditor-widgets-marc21.inc
Administration -> Item types:
- greybox.inc
ILL requests:
- ill-list-table-strings.inc
Web installer
- installer-intranet-bottom.inc
Web installer -> Onboarding
- installer-strings.inc
Lists -> List contents -> Merge records
- merge-record-strings.inc
Patrons -> Patron -> Change password
- password_check.inc
- str/members-menu.inc
Patrons -> Patron -> Print summary
- slip-print.inc
Circulation -> Check out
- timepicker.inc
Administration -> System preferences:
- str/tinymce_i18n.inc
- wysiwyg-systempreferences.inc
Cataloging -> Z39.50 Search:
- z3950_search.inc
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch removes "circulation" and moremember" templates functions
for Datepicker plugin. They now use options common for all inputs with
"datepicker" class and get "minDate" option from class "futuredate" assigned
function in "calender.inc".
To test:
- Apply patch
- Add holds for patron
- Use "Suspend all holds" calendar
=>Calendar greys out dates past from today
Signed-off-by: David Roberts <david.roberts@ptfs-europe.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
They are skinny and different from others.
Not that a problem, I am too.
But I do not think it is what they need.
Test plan:
Edit a patron and take a look at the input for "Date of birth"
=> Before this patch they are not looking great
=> After this patch they are beautiful
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
This patch updates the styling of form fields which are configured to
use the jQueryUI datepicker widget. Some CSS has been added, and the
default datepicker configuration has been changed.
To test, apply the patch, rebuild the staff client CSS file, and clear
your cache if necessary. Test pages which include a datepicker to
confirm that they look correct and work correctly. Some examples:
- Circulation -> Check out -> Specify due date
- Patrons -> Add patron -> Date of birth, registration date, expiry
date fields
- Serials -> Search subscriptions -> Search results page sidebar
- Tools -> News -> Add news item
And confirm that this change hasn't adversely affected the calendar
tool:
- Tools -> Calendar
Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Pierre-Marc Thibault <pierre-marc.thibault@inLibro.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Includes:
* code factorization
Some code from subscription & Mana-KB has been factorized in order to speed-up next developments
* SytemPreferences:
Mana Activation:
- add a value "no, let me think about it", that is the default value.
- as long as this value is selected, messages ask if user want to activate it ( in Administration and Add-subscription(page 2) )
AutoShareWithMana
- Add the syspref AutoShareWithMana: user can automatically share infos with Mana-KB (not set by default)
* Interface :
- On mana-search, rows are now sorted by date of last import, then by number of users
- Windows redesigned to improve the user experience
* New Feature : report a mistake.
- people can now report an invalid data (wrong, obsolete,...)
- if a data is reported as invalid many time, it will appear differently
- Added few tooltip (to explain the fields last import, nb of users, to explain the new feature)
- When reporting a data as invalid, a comment can also be added. Koha will then display comments related to data in result lists
* API (svc/mana)
- add svc/mana/addvaluetofield: allows to ask mana incrementing a field of a resource
- no hardcoding for resources in the code of api (api needs to be called with a ressourcename)
* New feature : SQL report sharing
- Create Koha::Report.pm and Koha::Reports.pm, objects class for Reports
- New feature: share reports with Mana-KB
- New feature: search report in Mana-KB with keywords
- New feature: load reports from Mana-KB
Test plan:
1 - Apply Patch + update database
2 - Copy the three lines about mana config in etc/koha-conf.xml in ../etc/koha-conf.xml (after <backupdir> for example)
<!-- URL of the mana KB server -->
<!-- alternative value http://mana-test.koha-community.org to query the test server -->
<mana_config>https://mana-kb.koha-community.org</mana_config>
3 - Check Mana syspref and AutoShareWithMana syspref are not activated
4 - Search the syspref ManaToken and follow the instructions
5 - subscriptions
- Try create a new subscription for a first serial => Mana-KB shouldn't show you anything (except if the base hase been filled)
- Share this serial with Mana-KB (on the serial individual's page there must be a Share button)
- Try to create a new subscription for serial nr1 => a message should appear when you click on "next", click on "use", the fields should automaticaly appear
- Activate AutoShareWithMana => Subscriptions
- Create a new subscription for a second serial
- There shouldn't be any Share button
- Create a second subscription => the message should appear, click again on use
6 - SQL Report
- Create a new SQL report, without notes.
- On the table with all report (reports > use saved), there should be the action "Share"
- If you click on share, you have an error message
- Create a new report, with a title and notes longer than 20 characters
- You can share it with mana => you will have a success message
- On (report > use saved), there must be a message inviting you to search on Mana-KB for more results, enter a few word from title, notes, type of the report you shared, it should appear. You can use it, it will load it into your report list.
7 - Report mistakes.
- On any table containing Mana-KB search results, you can report a mistake and add a comment.
8 - For each previous test, try to send wrong data, to delete the security token, to send nothing: it should show a correct warning message.
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Rebased-by: Alex Arnaud <alex.arnaud@biblibre.com> (2018-07-04)
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch removes the custom javascript form validation from three
templates: Budgets, budget planning, and contracts. Validation via the
validation plugin is done instead.
This patch also removes use of event attributes like onclick and
onchange. Also changed: I added the "Required" text next to required
fields as necessary.
To test, apply the patch and go to Administration -> Budgets.
- Test the budget creation process for adding, editing, and duplicating
budgets. In all cases:
- The start date and end date should be required
- You should be warned if you enter an end date which falls before the
start date.
- The description should be required
- The budget amount should be required to be a number
To test the budget planning page:
Note that much of the JS removed from this template was unused. It
looked for inputs by the name 'est_total' which don't exist.
- When viewing the table of funds for a budget, select a choice from the
'planning' toolbar menu.
- Verify that after entering a numeric value in any cell, the
'remaning' value at the end of the row is correctly updated.
- Verify that after entering non-numeric data an error is displayed.
- Verify that clicking the 'auto-fill' button at the end of the row
works to fill any empty or zero-value fields with the remaning funds
available.
To test the vendor contracts page:
- Go to Acquisitions -> Vendor -> Contracts
- Add or edit a contract
- Confirm that name, start date, and end date are required.
- Confirm that you are warned if you enter an end date which falls
before the start date.
Signed-off-by: Michal Denar <black23@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Here we go, next step then.
As we did not fix the performance issue when autofiltering
the variables (see bug 20975), the only solution we have is to add the
filters explicitely.
This patch has been autogenerated (using add_html_filters.pl, see next
pathces) and add the html filter to all the variables displayed in the
template.
Exceptions are made (using the new 'raw' TT filter) to the variable we
already listed in the previous versions of this patch.
To test:
- Use t/db_dependent/Koha/Patrons.t to populate your DB with autogenerated
data which contain <script> tags
- Remove them from borrower_debarments.comments (there are allowed here)
update borrower_debarments set comment="html tags possible here";
- From the interface hit page and try to catch alert box.
If you find one it means you find a possible XSS.
To know where it comes from:
* note the exact URL where you found it
* note the alert box content
* Dump your DB and search for the string in the dump to identify its
location (for instance table.field)
Next:
* Ideally we would like to use the raw filter when it is not necessary
to HTML escape the variables (in big loop for instance)
* Provide a QA script to catch missing filters (we want html, uri, url
or raw, certainly others that I am forgetting now)
* Replace the html filters with uri when needed (!)
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
This patch makes 2 changes:
1 - Global datepicker defaulted to c-100:c+10
2 - Dateofbirth datepicker defaulted to c-100:c
To test:
1 - Open some date pickers (patron entry, subscriptions, anywhere really)
- Make sure to check some dateofbirth datepickers
2 - Note that default is 10 years in either direction, updated when you
select
3 - Apply patch
4 - Note we now get -100 years / +10 years from current selection
5 - Now find a dateofbirth datepicker and note default is -100:+0
6 - Sign off
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Tested 3 patches together on current master
- Dropped database
- Recreated database
- Went through installer
- Language en, Marc21
- Installed mandatory data only
- Went through Onboarding tool
- After finishing, logged in as superlibrarian
that was created by onboarding tool
Everything worked fine.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Iso dates are yyyy-mm-dd, the is_valid JS function
expects \d{2}-\d{2}-\d{4} when it should be \d{4}-\d{2}-\d{2}
Test plan:
Switch DateFormat to iso
Set a due date using the datepicker
=> Should work as expected
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
01/01/01984 should not be considered as a valid date.
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
If a date does not contain leading zeros for day and month, the date
will be refused.
parseDate function considers 1/1/1990 as a valid date, but our perl code
does not. We must refuse it.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Before this patch, the user was still allowed to enter a valid date.
Now, if the date is not valid, the input is emptied.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
The date format is now displayed on the warning popup.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
In order to remove accessibility issues due to the readonly attributes
on date inputs, this patch will remove them and introduce a javascript
validation on them.
This patch is not perfect for some reason:
I didn't manage to force the user to select a valid date. One solution
would be to reopen the datepicker plugin until a valid date is inserted.
But it could be annoying for users (and for me: I did not manage to
implement this solution).
You will note that input is emptied if the date is not valid. This is a
quick and efficient solution to prevent submitting invalid date and make
Koha explodes. A proper solution would be to implement the check server
side send a friendly message to the user.
Test plan:
For all inputs, try an invalid and a valid date.
1/ Debar a patron
2/ On the checkout tables (circulation and moremember), add a renewal
due date (at the bottom of the tables)
3/ On the checkout page, specify a due date
4/ On the return page, specify a return date
5/ On the invoice page (acquisition module), enter a shipment and
billing date
6/ On the invoice search page (invoices.pl) use filters shipment and
billing dates
7/ On the offline circ page, specify a due date
8/ On the edit patron page (memberentry), add a debarment
9/ On the reserve page (reserve/request.pl), use the date inputs to
suspend until a defined date
10/ Edit patrons in a batch (tools/modborrowers.pl) and use the
registration and expiry date inputs
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch is to display corrextly the new dmydot date format e.g. after
using the datepicker or in messages for the user, in following files:
- koha-tmpl/intranet-tmpl/prog/en/includes/calendar.inc
- koha-tmpl/intranet-tmpl/prog/en/includes/date-format.inc
- koha-tmpl/intranet-tmpl/prog/en/includes/patron-search.inc
- koha-tmpl/intranet-tmpl/prog/en/modules/tools/holidays.tt
- koha-tmpl/opac-tmpl/bootstrap/en/includes/calendar.inc
- tools/holidays.pl
To test:
- Apply patch
- Make sure that you have syspref dateformat set to dmydot
- Use datepicker in OPAC (modify birth date), verify that after
choosing a date, it is displayed correctly in the datepicker
- Use datepicker at several places in OPAC, verify that after choosing
a date the date displays properly in datepicker and that the dater format
is properly indicated (e.g. near birth date or near "Specify due date").
- Verify that datepicker works well with hoiday editing and that "From date:"
displays properly
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
- new TT plugin for Borrowers, that at present supplies
a method for determining if the patron is restricted
- setting the default value of SpecifyReturnDate to false
during upgrade to avoid an unwelcome surprise
- validate the return date on the client side before
allowing the form to be submitted.
Signed-off-by: Petter Goksoyr Asen <boutrosboutrosboutros@gmail.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
- the dateformat value is send to all templates (from
C4::Auth::get_template_and_user)
- remove all assignment of dateformat in all .pl files
- Remove "all" occurrences (those I found!) of dateformat_*
From now the only way to get the date format is a string comparaison
(dateformat == "metric")
Checked with the command:
git grep "\(dateformat_us\|dateformat_metric\|dateformat_iso\)" | grep
-v translator
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Tested all the datepickers I could find, looks good.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I tested most scripts affected by this patch and visually verified
all changes. Functionality is unaffected.
Signed-off-by: Mason James <mtj@kohaaloha.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
When I replaced the old calendar widget with the jQueryUI version
we lost a JavaScript function which is required by a couple of
pages: Date_from_syspref. This patch adds the function back
to the calendar include and corrects variables in the two
affected templates to make it work again.
To test:
- create a new contract. Submitting should work properly and
without JavaScript errors.
- Open the serials claims page (serials/claims.pl) and filter
the results by date. Submitting the filter form should
work properly and without JavaScript errors.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Both tests passed.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
All instances of the old DynArch calendar have been replaced with
jQueryUI versions and the old library files have been removed.
calendar.inc has been modified to include jQueryUI localization
strings and global configuration options. Just add a "datepicker"
class to an input field to trigger a datepicker prompt.
If you would like two fields in one from to limit each other (one
is date from, one is date to), add these classes to each:
"datepickerfrom" and "datepickerto." This will prevent an invalid
entry, e.g. a date in the latter which falls before the former.
jQueryUI is now upgraded to the latest verision, 1.8.21.
Edit: Now with proper translatability, date formatting, first day
of the week handling, and RTL support.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Ian Walls <koha.sekjal@gmail.com>
QA Comment: rebased on current master; minor merge conflicts with other patches pushed
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
This patch copies the calendar's language strings from a stand-
alone javascript file into calendar.inc where they can be
translated along with other strings.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
This is likely the durable fix to bridge the gap between syspref on the server
and client side validation scripts. It may be useful to separate Date_from_syspref
from the calendar js, but at this time their applicability is 1-to-1.
Note also js debug variable and CGI param('debug') responsiveness.
Signed-off-by: Chris Cormack <crc@liblime.com>
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Output.pm: sanatizing variable names
ran perl -pi~ -e 's/\/includes\/calendar\//\/lib\/calendar\//' * in every staff template dir
Signed-off-by: Chris Cormack <crc@liblime.com>
cvs -z3 -d:ext:kados@cvs.savannah.nongnu.org:/sources/koha co -P koha
find koha.precrash -type d -name "CVS" -exec rm -v {} \;
cp -r koha.precrash/* koha/
cd koha/
cvs commit
This should in theory put us right back where we were before the crash
