If you manually visit the following links when you only have
permission to run reports, you'll still be able to access the ability
to create and edit reports:
/cgi-bin/koha/reports/guided_reports.pl?phase=Create%20report%20from%20SQL
/cgi-bin/koha/reports/guided_reports.pl?phase=Edit%20SQL
This patch ties these 2 unaccounted for phases to the create_reports
permission.
With patch, issue no longer can be reproduced.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
(cherry picked from commit 2fdfbaf0dd)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
(cherry picked from commit 4b71c92397)
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Conflicts:
reports/guided_reports.pl
To test:
Set 'delimiter' system preference to 'tabs'
Export a report as csv
Open the file in text editor and note fields separated by character 't'
Apply patch
Export report as CSV
Open file in text editor and note tabs are used to separate fields
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
tabs now, no errors.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Mason James <mtj@kohaaloha.com>
If a report is duplicated from the report list, the new report will
contain the tag (<<YEAR>> for instance), but from the reports results
page it copies the values used for the results.
Test plan:
Create a new sql report with tags
Duplicate it from the report list: no expected changes
Run it and duplicate it: the tags must not have been replaced
Signed-off-by: Andreas Roussos <arouss1980@gmail.com>
Ran and duplicated a report, the tags remained intact.
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit 50a37fbf5b)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
If you click the clear button to clear the search term it does take the search
term away. However, the next time you click on "Saved reports" the search term
is still there.
TO TEST:
1. Reports > Use saved
2. Filter on anything (date/author/keyword). Let say "foo" in keyword.
3. Click the Clear link on the Filter form. You can see that "foo" is removed
from keyword, and all the saved reports are displayed.
4. Click "Saved Reports" on the left. You can see that "foo" reappears in
keyword filter.
5. Apply the patch, and repeat steps 2-4.
Signed-off-by: Jesse Maseto <jesse@bywatersolutions.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(cherry picked from commit aa0e27ea08)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
An existing 'execute' parameter is already passed to the template when
we need to display the 'Download' button, so let's use it instead of
creating a new one.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
(cherry picked from commit c2f53bd039)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
To test:
1) Create a new SQL report or edit a report
2) Ensure that the download option does NOT show in the toolbar
3) Save and run the report
4) Confirm that download option DOES show in toolbar as a dropdown with
the 3 options (csv, tab and ods)
5) Confirm that downloading all 3 file types works as expected
Sponsored-by: Catalyst IT
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
(cherry picked from commit e7ac7abf16)
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
This patch replaces the occurrences of
my @foo = $cgi->param('foo');
with
my @foo = $cgi->multi_param('foo');
perl -p -i -e
's/^(\s*my\s*@\w+\s*=\s*)\$(cgi|input|query)\->param\(/$1\$$2\->multi_param\(/xms'
**/*.pl
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
The commit b5ecefd485
Date: Mon Feb 3 18:46:00 2003 +0000
had a funny description:
Added function to check if a MARC subfield name is "koha-internal"
(instead of checking it for 'lib' and 'tag' everywhere); temporarily
added to Koha.pm
"Temporarily", since 2003, everything is relative, isn't it? :)
The thing is that GetMarcStructure returns hash like
field_200 => {
subfield_a => {
%attributes_of_subfield_a
},
%attributes_of_field_200
}
The attributes for field_200 can be 'repeatable', 'mandatory', 'tag', 'lib'.
We don't want to loop on these values when looping on subfields.
Since there are just { k => v } with v is a scalar (string), it's easier
to test if we are processing a subfield testing the reference.
At some places, we don't need to test that, we are looping on values
from MARC::Field->subfields which are always valid subfields.
Test plan:
1/ Edit items using the batch item mod tool
2/ display and edit items via the cataloguing module.
You should not see any changes between before and after the patch
applied.
Tech notes:
We need to check what we are processing when we loop on 'subfields' from
GetMarcStructure, not from MARC::Field->subfields.
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
C4::Koha::IsAuthorisedValueCategory contains only 2 useful calls, from
C4::Reports::Guided and reports/guided_reports.pl
It can be replaced with
Koha::AuthorisedValues->search({ category => $authorised_value})->count
Test plan:
1/ Create a sql report using an authorised value category, something
like:
SELECT COUNT(*) FROM items where itemlost=<<lost|LOST>>
2/ Execute the report and confirm that everything works fine.
3/ Create a sql report using a nonexistent authorised value categor,
something like:
SELECT COUNT(*) FROM items where itemlost=<<lost|NONEXIST>>
4/ When saving the report, you should get a warning message
"lost: The authorized value category (NONEXIST) you selected does not exist."
5/ Save anyway and execute the report, you should get the same warning
message.
QA:
git grep IsAuthorisedValueCategory
should not return any results
prove t/db_dependent/ReportsGuided.t
should return green
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as described
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
The C4::Koha::AddAuthorisedValue is only called twice from
reports/guided_reports.pl and insert an authorised value.
This job can be achieve easily using the Koha::AuthorisedValue module.
Test plan:
1/ Create a new guided report
2/ Use an existing group and/or subgroup of reports
3/ Save
4/ Update an existing report
5/ Use an existing group and/or subgroup of reports
6/ Save
7/ Create or update an existing report
8/ Remove its assigned group and subgroup
9/ Save
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
Initialising $phase variable to be '' if not defined.
To test:
1) Go to Reports -> Guided Reports Wizard
2) Notice warns
3) Apply patch
4) Refresh page
5) Confirm warns are gone and page still works as it should
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Warns are gone. Page still works as expected
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Amended patch:
-my $phase = $input->param('phase');
-$phase //= '';
+my $phase = $input->param('phase') // '';
Signed-off-by: Brendan Gallagher brendan@bywatersolutions.com
This patch fixes following issues with breadcrumbs and html page title
in Home > Reports > Guided reports wizard:
- Sometimes, breadcrumbs display a stray > at the end
- While creating a report, steps are not displayed in breadcrumbs and
do not appear in html page title
- html page title is divided by newlines
To test:
- Apply patch
- Go to Home > Reports > Guided reports wizard
- Go to all pages including the steps for creating a new report and
verify
- that the breadcrumbs display properly and make sense
- in html source, the page title makes sense and displays on one line.
Signed-off-by: Hector Castro <hector.hecaxmmx@gmail.com>
Works as descrived
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Brendan A Gallagher <brendan@bywatersolutions.com>
To test:
- Create an SQL report with column names containing UTF characters
- Run the report
=> FAIL: The column names are double encoded
- Export the report
=> FAIL: The column names are double encoded in the exported file
- Apply the patch
- Re-run the report (reload works)
=> SUCCESS: Encoding correct
- Export the report
=> SUCCESS: Encoding correct
- Sign off :-D
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Fix SQL row data and headers enconding problem
To test:
-Apply patches
-Follow previous test plan
-Notice the headers and row data is displayed in UTF-8
without double encoding
-Save in Comma separated text, Tab seprated text, and Open Document.
-Verify in the three options the file exported is Ok
Signed-off-by: Frédéric Demians <f.demians@tamil.fr>
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This patch removes stray C4::Dates from following files:
reports/borrowers_stats.pl
To test: Verify that C4::Dates is not used in the file
reports/guided_reports.pl:
To test:
- Run a saved report with date input and with date range input, e.g.
- Verify that you are asked for date range or date and that the results
are the same as without patch
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The cache_expiry is not saved when updating a SQL report.
Test plan:
0/ Enable memcached
1/ Create a sql report
2/ Edit it and change the cache expiry value
3/ Edit again
=> The value should have been updated.
Signed-off-by: Frederic Demians <f.demians@tamil.fr>
Repeatable bug. Solved with this patch.
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
This patch removes C4::Dates from files:
- reports/guided_reports.pl
- reports/dictionary.pl
- C4/Reports/Guided.pm
To test:
- Go to Home > Reports > Guided reports wizard
- Then go to 'View Dictionary' (menue at teh left)
- Click 'New definition' and step through
- In step 2. select e.g. borrowers
- In step 3 select a date field
- In step 4, select date range and test start / end dates
- In step 5, verify that dates display properly
- Save and verify that dates are insertet properly in sql definition
- Go back to Home > Reports > Guided reports wizard
- Step through the wizard and verify that it works as before.
http://bugs.koha-community.org/show_bug.cgi?id=14982
Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
The regex /|date>>/ will match much more than you like :)
The unescaped pipe is bad, but you also need to remove the >> because
the split a few lines above it removes them already.
This allows you to recover from an error like this one, running another
report with a string parameter:
The given date (india%) does not match the date format (us) at
Koha/DateUtils.pm line 144.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Amended for possible spaces around the word date.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
The issue is that SQL expects ISO dates, but the user may wish to view dates according to the dateformat system preference.
By detecting a date preference, the non-ISO dates can be converted to ISO dates before being stuffed back into the SQL query to be executed.
TEST PLAN
---------
1) Add a report with date parameters.
-- I used 'Holds placed in date range' from
http://wiki.koha-community.org/wiki/SQL_Reports_Library
2) Set your dateformat to YYYY-MM-DD
3) Run the report
-- Note the SQL reads
"... BETWEEN '{date formatted in YYYY-MM-DD}'..."
-- If there is supposed to be data, there is some.
4) Set your dateformat to MM/DD/YYYY
5) Run the report
-- Note the SQL reads
"... BETWEEN '{date formatted in MM/DD/YYYY}'..."
-- If there is supposed to be data, there is none.
6) Apply patch
7) Repeat steps 2-5
-- The SQL will always read YYYY-MM-DD (ISO) format.
-- The report will have data, if there is some.
8) koha qa test tools.
Signed-off-by: Amit Gupta <amit.gupta@informaticsglobal.com>
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Adding a QA follow-up.
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
Patch adds a 'clear' link next to the 'Apply filters' button to
empty out the form fields.
To test:
- go to the reports module
- make sure you have some saved reports
- search your saved reports using the author, keyword and date filters
- verify searching works as expected
- verify the new 'clear' link works as expected
Tested couner patch, followed test plan, works as expected. QA tools ok.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@unc.edu.ar>
See QA comment #5
- new reports log their Id instead of 0
- format info: <name> | <sql>
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch sets adds the possibility to log new, update and delete actions for saved reports.
To test:
-Apply patch
-Run updatedatabase.pl
-Enable system preference ReportsLog
-Create, duplicate, edit and delete saved reports
-Go to Home > Tools > Logs
-Verify that you can select "Reports" in Modules list
-Verify that your actions were logged
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Nicole Engard <nengard@bywatersolutions.com>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Remove an instance of CGI::scrolling_list from this file
To test:
1) Go to Reports, Guided report wizard, New SQL report
2) Create a report with some auth value list, e.g.
SELECT surname,firstname FROM borrowers WHERE branchcode=<<Enter patrons library|branches>>
Save
3) Clic on 'Run this report", look at the dropdown, that will be changed
4) Apply the patch
5) Reload, check dropdown and any regression
Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Jonathan Druart <jonathan.druart@koha-community.org>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce:
- Go to Home > Reports Guided reports wizard
- Create report from SQL
- Enter something like: select holdrio from borrowers
- Save SQL
- run report
Result:
Can't use an undefined value as an ARRAY reference at /usr/share/kohaclone/reports/guided_reports.pl line 932.
expected: graceful error message
- Change sql to something like: select id from holdrio;
- Save SQL
- Run report
Result:
Can't use an undefined value as an ARRAY reference at /usr/share/kohaclone/reports/guided_reports.pl line 932.
expected: graceful error message
- Change sql to something like: pling from plong
- Save SQL
Result (after saving): Message "The database returned the following error: 1"
Expected: Meaningful message "The database returned the following error: No SELECT" (similar to forbidden statements as UPDATE)
Test plan:
- Apply patch
- Try to reproduce issues above. They should be resolved.
Signed-off-by: Nick Clemens <nick@quecheelibrary.org>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
On the saved report list, the filters on the left are not displayed.
It means that some can be set, but the user has not visible feedbacks.
How filters work here:
If a user set a filter, it is saved in the session. Next time he will
come on this search, the previous values will be kept.
This patch just displayed the filter's values in the input fields.
Test plan:
Search for reports by date, author and keyword.
The filters should be displayed after you have clicked on the submit
button ("Apply filter").
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch propoeses the name of a saved report as part of the download file name.
To test:
- Apply patch
- Got to Home > Reports > Guided reports wizard > Saved reports (or create a new report from sql)
- Run a saved report
- Download the report (as csv, tab, ods)
Result: The downlaod file name proposed should be prepended by the report name, separated with a -
- Bonus test: Try to downlaod saved reports which have special character in their name.
NOTE: Used "ñ/â is N/A" as a report name. The /'s were translated
to underscored, but the letters were as expected.
Signed-off-by: Mark Tompsett <mtompset@hotmail.com>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Chris Nighswonger <cnighswonger@foundations.edu>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
http://bugs.koha-community.org/show_bug.cgi?id=9987
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
If no caching system is up ($usecache == 0), the public parameter is
lost on the step 3.
The hash passed to the template looks like:
'cache_expiry', 300,
'cache_expiry_units',
'public', 1
So the template receives cache_expiry = 300, cache_expiry_units =
'public' and 1 = undef.
This patch fixes the problem passing the cache_expiry* parameters only
if the usecache is set.
Test plan:
0/ Disable any caching system
1/ Create a new public report and go up to the 6th step, save the report
and verify the report is created as public
2/ Enable a caching system
2/ Create a public report with a cache expiry value, save it and verify
the report is created as public and the cache expiry value is correct.
Signed-off-by: Brendan Gallagher <brendan@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11679 introduced a FIXME for this but it is wrong. The strings have
to be encoded before generating the ods file.
However, it is useless to decode column names.
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
To reproduce, edit, index notice with utf-8 char and search for it
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
See the wiki page for the explanation.
Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Signed-off-by: Dobrica Pavlinusic <dpavlin@rot13.org>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
By tweaking the GetReservedAuthorisedValues function in
C4::Reports::Guided, biblio_framework can be added as a dropdown
list into the guided reports parameters.
The change in C4/Reports/Guided.pm required a test, which is
found in t/db_dependent/ReportsGuided.t
Code was then added to reports/guided_reports.pl to build the
appropriate hash to trigger the proper dropdown list.
TEST PLAN
---------
1) Apply patch
2) prove -v t/db_dependent/ReportsGuided.t
-- all should pass, this confirms that both
C4/Reports/Guided.pm and this test file work.
3) Log into staff client
4) Reports
5) Create from SQL
6) Enter appropriate information like:
Report name: Test 13141
-- no need to change Report group or Report is public or Notes or Type
SQL:
SELECT CONCAT('<a href=\"/cgi-bin/koha/catalogue/detail.pl?biblionumber=',
biblio.biblionumber,'\">',biblio.biblionumber,'</a>') AS
BiblioNumbers, title, author, frameworkcode
FROM biblio
WHERE frameworkcode=<<Enter the frameworkcode|biblio_framework>>
7) Save report
8) Run report
-- The parameter entry page should have a drop down of
framework codes.
9) Select a framework code, and click Run the report
-- The displayed SQL should have a "frameworkcode=" portion
matching the selected framework.
10) Run the koha qa test tool.
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Test plan followed successfully.
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
This patch removes hardcoded descriptions and sets them in the templates
using the variable content as id.
To test, create a new guided report and verify the 'module to report on' dropdown
shows as usual [1]. Functionality shouldn't get changed.
The patch also changes the dictionary pages where 'area' should be displayed/selectable
with the same strings as the guided reports. Try all the possible disctionary pages.
The last page when creating a dictionary now shows the 'area description' instead of the
code. The same happens to the dictionary list once you have dictionaries saved.
[1] The following texts get changed:
Catalogue -> Catalog
Acquisition -> Acquisitions
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Bug 11679 introduces an ods export for reports.
It looks quite buggy:
1/ You get a Perl error if the report has no results
2/ The ods file contains 1 lines less than the total results.
Test plan:
After applying this patch, try to export a report which has no results
and verify you get an ods file with headers only.
Try to export a report which has a least 1 result and verify the
generated ods has the right number of lines.
Signed-off-by: Robert Higgins <robert.higgins@catalyst.net.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixes the reported problem, passes all tests and QA script.
Added the sign-off line for Robert.
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Since we switched to Template Toolkit we don't need to stick with the
sufix we used for HTML::Template::Pro.
This patch changes the occurences of '.tmpl' in favour of '.tt'.
To test:
- Apply the patch
- Install koha, and verify that every page can be accesed
Regards
To+
P.S. a followup will remove the glue code.
Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
When a user runs a report containing an SQL error, no
error is shown to the user. This patch fixes this.
To test:
1) Run a report with known good SQL.
2) No error is shown.
3) Run a report with bad SQL (eg. a typo in field name)
4) No error is shown.
5) Apply patch
6) Repeat 1-4. For the bad SQL report, the database error
should be shown.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds the ability to export the data generated by a report
into an Open Document spreadsheet file.
Test plan:
1/ Install the new dependency
2/ Verify you are able to generate an ods file from a
report result.
Tested with several reports and downloaded them as Open Document
Spreadsheet. Wors as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Verified tab and comma separated export still works correctly.
Verifid new ODS export works nicely.
Tested with data containing Arabic characters and German umlauts.
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
This patch adds the option to select multiple saved reports for
deletion.
To test you must have two or more saved reports to delete. Deletion
should work properly when:
- Selecting one report for deletion by checking the box.
- Selecting more than one report for deletion by checking boxes.
- Clicking the old "Delete" link
Clicking the delete button should prompt you to confirm. Clicking cancel
should cancel.
Clicking the delete button when no boxes are checked should trigger an
alert asking you to select reports for deletion.
Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Functional tests pass, template tests pass.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
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>
If you create an SQL report that includes one or more parameters,
using the 'rows per page' pulldown does not work. Instead, it will
prompt for the parameters again and shows the first page of output.
Test Plan:
1) Create a new report from sql as follows:
SELECT * FROM borrowers WHERE surname LIKE <<Last Name>> AND firstname LIKE <<First Name>>
2) Run this report
3) Change the 'Rows per page' and click 'Update'
4) This should kick you back to the start where the report asks you for your parameters
5) Apply the patch
6) Repeat step 3, this time is should work correctly
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works nicely now. All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
Adds decoding for cgi params (for completeness).
Apparently, the NAME attribute of DBI statement handle has a UTF8 bug.
Fixing this by decoding the returned column names.
Did this in a shared routine.
http://bugs.koha-community.org/show_bug.cgi?id=10110
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Copying test plan from bug report:
Example SQL:
select
branchname as "Bibliothek (üöä)",
branchname "Bibiothek (üäa)",
branchname
from branches where branchcode = <<Bibliothekskürzel|branches>>
1) Create report with given example SQL or your own including
some diacritics in the columnnames
2) Save the report and run it
3) Verify column names are broken before patch, but fixed after..
All tests and QA script pass.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
A user might create a SQL report that relies on non-existent authorised value categories.
Because of a typo, or just because they copy&pasted the report from the Wiki.
Use cases are:
- The user creates a report from SQL
a) Uses bad authorised values
b) Clicks 'Save Report'
c) Koha lists the problematic authorised values
d) The user decides to
e-1) Save it anyway, it gets saved
e-2) Edit the report, it gets back to where it chose 'Save Report'
- The user edits an already saved report (Update SQL)
a) Uses bad authorised values
b) Clicks 'Update SQL'
c) Koha lists the problematic authorised values
d) The user decides to
e-1) Save it anyway, it gets saved
e-2) Edit the report, it gets back to where it chose 'Update SQL'
- The user tries to run a saved report that contains bad authorised values, Koha advertises the problem and provides the user with a button 'Edit SQL' to fix things.
To test, just create a report from SQL using invalid authorised values like this (misspelled 'branch'):
SELECT *
FROM itemtypes
WHERE hola=<<Test branch1|branchee>> AND
hola2=<<Test branch2|brancha>>
Regards
To+
Notes:
- I added several comments on the code.
- Fixed an annoying warning of uninitialised variable also (refactored some tiny bits to do it).
- Added the following methods
- C4::Reports::Guided::GetReservedAuthorisedValues
- C4::Reports::Guided::GetParametersFromSQL
- C4::Reports::Guided::IsAuthorisedValueValid
- C4::Reports::Guided::ValidateSQLParameters
- C4::Koha::IsAuthorisedValueCategory
- Those methods could have been used to refactor this guided reports code as its *a bit messy*. I chose to do it in a new bug of course :-D.
- Fixed some trivial perlcritic -5 errors
- Removed some debugging stuff left by mistake
- Fixed some POD problems
- Optimal SQL-driven IsAuthorisedValueCategory method
- Thanks to Owen and Jared for their patience heh.
Sponsored-by: Universidad Nacional de Córdoba
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Comment: Work as described. No koha-qa errors.
Test:
Tried with examples (from help and test plan) reports, correctly
identifies invalid authorized values, and no problem with
authorized ones.
NOTE: Online help for this does not states that partial values
need to be between '%' in a SQLish way. Perhaps this could be
addressed inserting % in values or adding a checkbox (partial|exact).
Or changing help.
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
In current implementation (mostly commented out in this patch)
uses heuristic to guess which strings need decoding from utf-8
to binary representation and doesn't support utf-8 characters
in templates and has problems with utf-8 data from database.
With this changes, Koha perl code always uses utf-8 encoding
correctly. All incomming data from database is allready
correctly marked as utf-8, and decoding of utf8 is required
only from Zebra and XSLT transfers which don't set utf-8 flag
correctly.
For output, standard perl :encoding(utf8) handler is used
so it also removes various "wide character" warnings as side-effect.
Test scenario:
1. make sure that you have utf-8 characters in your biblio
records, patrons, categories etc.
2. try to search records on intranet and opac which contain
utf-8 characters
3. install language which has utf-8 characters, e.g. uk-UA
dpavlin@koha-dev:/srv/koha/misc/translator(bug_6554) $
PERL5LIB=/srv/koha/ perl translate install uk-UA
4. switch language to uk-UA and verify that templates
display correctly
5. test search and Z39.50 search and verify that caracters
are correct
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
I followed the test plan, adding utf-8 characters to library names,
patron categories, titles, and authorized values. I tried the uk-UA
translation and everything looked good.
When performing Z39.50 searches for titles containing utf-8 characters I
got results which were still occasionally contaminated with dummy
characters [?] but I assume this is Z39.50's fault not the patch's.
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com>
Already signed, add mine.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
- Filter by groups using tabs
- Filter by subgroups using a dropdown list under each tab
- Allow to create new group and subgroups when building a new report or
editing an existing report (no need to go through admin AV interface)
+ Possibility to duplicate a report (new link in the table)
Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
This patch adds the ability to select the number of row to show per page while
retaining the default rows per page as 20.
Test Plan:
1) Apply patch
2) Run a guided report that will have many resultant rows
3) Try the various rows per page options
4) Verify the rows per page selected is retained when paging through results
Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.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
- the DHTMLcalendar_dateformat variable is unused
Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Fixed conflicts:
- opac/sco/sco-main.pl
- reports/acquisitions_stats.pl
- tools/cleanborrowers.pl
All tests pass, perlcritic problems appeared in some files
before and after these patches were applied.
Checked sorting in following pages:
- acqui/addorderiso2709.tt - list of staged imports in acq
- acqui/histsearch.tt - sorting of dates in acq search result list
- acqui/invoices.tt - billing date in list of invoices in acq
- acqui/lateorders.tt - list of late orders in acq
- acqui/ordered.tt - ordered titles and estimated costs for a fund
- acqui/parcels.tt - receive shipment page
- acqui/spent.tt - received titles and actual costs for a fund
...
- serials-search.tt - subscription search result list
...
- opac/sco/sco-main.tt - due dates in list of checked out items
- reports/acquisitions-stats.tt - date searches, display of dates
- tools/cleanborrowers.tt
- tools.holidays.tt - different views of dates library is closed,
adding dates
Checked dates display according to system preference everywhere and
searching, entering dates etc. still worked as expected.
Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com>
The fix for Bug 7993 removed some lines from guided_reports.pl
which passed a new report's name and id to the template after
saving. For some reason this was removed, making it impossible
to run or edit a new report immediately after saving.
This patch adds back that part of the script which passes those
variables to the template. Before this patch, after adding a new
SQL report you would not see a "run this report" link. The
"run this report" and "edit" buttons in the toolbar would not
work. After applying the patch these should work.
Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Tested creating reports and was able to run them after saving.
Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
David Cook
Nick Clemens
Jonathan Druart
Frédéric Demians
Aleisha
Marc Véron
Tomas Cohen Arazi
Hector Castro
Marcel de Rooy
Mark Tompsett
Jonathan Druart
Bernardo Gonzalez Kriegel
Jonathan Druart
Pasi Kallinen
Owen Leonard
Galen Charlton
Kyle M Hall
Dobrica Pavlinusic
Julian Maurice