[Koha-bugs] [Bug 10565] Add a "Patron List" feature for storing and manipulating collections of patrons
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10565 Robin Sheat changed: What|Removed |Added CC||ro...@catalyst.net.nz --- Comment #45 from Robin Sheat --- Too late to do much about it now, but this doesn't follow: http://wiki.koha-community.org/wiki/Coding_Guidelines#PERL14:_Exports and arguably the next one too. We should try to avoid littering the namespace with default exports. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11992] detail.pl display issue after item on hold & in transit is checked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11992 --- Comment #1 from Heather Braum --- Created attachment 26541 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26541&action=edit Screenshot of item in transit on detail-pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11992] New: detail.pl display issue after item on hold & in transit is checked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11992 Bug ID: 11992 Summary: detail.pl display issue after item on hold & in transit is checked in Change sponsored?: --- Product: Koha Version: 3.14 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: hbr...@nekls.org QA Contact: testo...@bugs.koha-community.org CC: gmcha...@gmail.com Created attachment 26540 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26540&action=edit Screenshot of detail.pl item statuses after item is checked in before confirm button When an item on hold is in transit to a library, and is checked in upon receiving it, BEFORE the confirm button is clicked, but AFTER the item is checked in, the detail.pl page shows this status for the item: "Item-level hold for [patron] for delivery at [library name] (placed date)." [attached screenshot "Screenshot of detail.pl item statuses after item is checked in before confirm button"] The item status no longer shows that the item is in transit, even though the confirm button hasn't been clicked yet. Until that confirm button is clicked, I think that status should remain, "In transit from [library a] to [library b] since [date] item-level hold for [patron] for delivery at [library b] (placed [date])". [attached screenshot of item in transit on detail-pl] -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11991] New: "Item is already waiting" message after in-transit item on hold checked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11991 Bug ID: 11991 Summary: "Item is already waiting" message after in-transit item on hold checked in Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: hbr...@nekls.org QA Contact: testo...@bugs.koha-community.org CC: gmcha...@gmail.com Created attachment 26539 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26539&action=edit Screenshot of the hold found (item is already waiting message) When an item on hold that is in transit to another branch is checked in at the library it is transiting to, the confirmation message appears with the text, "hold found (item is already waiting)..." with the confirm/print and confirm buttons. [see attachment for the message screenshot] I don't think the "item is already waiting" text is correct or useful here, as the item just arrived at the library. Is that text purposeful? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11991] "Item is already waiting" message after in-transit item on hold checked in
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11991 Heather Braum changed: What|Removed |Added Version|unspecified |3.14 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11990] New: Holds ratio report sorts wrong
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11990 Bug ID: 11990 Summary: Holds ratio report sorts wrong Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: ro...@catalyst.net.nz QA Contact: testo...@bugs.koha-community.org CC: gmcha...@gmail.com Created attachment 26538 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26538&action=edit Screenshot showing the wrong sorting The "holds" column in the holds ratio report sorts lexicographically rather than numerically. It probably should also sort in reverse by default, so the things with more holds show at the top. See screenshot. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11801] In transit hold items incorrectly labeled as "Waiting to be pulled" on request.pl
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11801 Heather Braum changed: What|Removed |Added CC||hbr...@nekls.org -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7939] Separate po files for different MARC dialects
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7939 --- Comment #5 from Bernardo Gonzalez Kriegel --- On point 7.a), an error, must be sort old | uniq | tee s-old | wc -l > n-old -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7939] Separate po files for different MARC dialects
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7939
Bernardo Gonzalez Kriegel changed:
What|Removed |Added
Attachment #26530|0 |1
is obsolete||
--- Comment #4 from Bernardo Gonzalez Kriegel ---
Created attachment 26537
-->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26537&action=edit
Bug 7939 - Separate po files for different MARC dialects
[PRELIMINAR 2 - not in final form but can be tested]
This patch implements separate PO files for
different MARC dialects.
It depends on correct filenames, i.e. it will build PO
files using files with/without "unimarc|normarc|marc21"
on their names.
Prominent changes:
A) tmpl_process3.pl
three new options: exclude or include certain filenames
and a new source dir that can have multiple values
(I opted to add this last feature and not change current
source dir in order not to brake current usage)
Minor change on use of msgmerge, now there are no backup
files (*~) and obsoleted translations are removed (to
produce smaller files) [this can be on another bug, is
not strictly related with the pourpose of this bug]
B) LangInstaller.pm
added definitions to create or update nn-NO-{MARCFLAVOR}.po
and modification on install procedure to handle multiple
target dirs
C) Standarization of filenames
OPAC prog po file is now xx-YY-opac-prog.po
STAFF po file is now xx-YY-staff-prog.po
MARC dialects po files are xx-YY-marc-{MARCFLAVOUR}.po
[again, renaming not related, can be in it's own bug]
To test:
1) Update po files for your preferred language, ej. nn-NO
cd misc/translator
perl translate update nn-NO
(do it twice if there are warnings)
2) Do some copying/renaming
cp po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-marc-UNIMARC.po
cp po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-marc-NORMARC.po
cp po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-marc-MARC21.po
mv po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-staff-prog.po
mv po/nn-NO-i-opac-t-prog-v-3006000.po po/nn-NO-opac-prog.po
(most MARC dialect strings are on staff, so we use that as basis)
3) Apply the patch
4) Update again to fix translation files, verbose
perl translate update nn-NO -v
5) Install language, verbose, verify translations
perl translate install nn-NO -v
6) Create translation files
rm po/nn-NO*
perl translate create nn-NO
we must have this list:
po/nn-NO-marc-MARC21.po
po/nn-NO-marc-NORMARC.po
po/nn-NO-marc-UNIMARC.po
po/nn-NO-opac-bootstrap.po
po/nn-NO-opac-ccsr.po
po/nn-NO-opac-prog.po
po/nn-NO-pref.po
po/nn-NO-staff-help.po
po/nn-NO-staff-prog.po
[staff-help could be more properly staff-prog-help,
another rename]
Additional tests:
7) Number of msgids
7.a) Before patch and after upgrade, extract and count msgids
for i in $(ls po/nn-NO-*po); \
do msginit -i $i -o nn-old.po --no-translator --no-wrap --locale=nn_NO; \
egrep ^msgid nn-old.po >> old; \
done
sort new | uniq | tee s-old | wc -l > n-old
s-old: have all msgids
n-old: number of msgids
7.b) After patch and after creation of new files
Repeat procedure, diferent files (s-new, n-new)
7.c) Compare (diff s-old snew), they are the same
(save for a strange UNIMARC char in my case)
8) Installed dirs/files
8.a) List of EN dirs/files
cd koha-tmpl
find | egrep "/en/" > en
8.b) List of nn-NO dirs/files. After patch and language install
cd koha-tmpl
find | egrep "/nn-NO/" | sed 's|/nn-NO/|/en/|' > nn
8.c) Compare (diff en nn), they are the same
(save for a bogus help/nn-NO dir, without files. Working for a solution)
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10500] Improve isbn matching when importing records
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10500 Nicole C. Engard changed: What|Removed |Added Status|Passed QA |Failed QA --- Comment #29 from Nicole C. Engard --- Peggy found an error - well we found an error when Peggy reported a problem so I'm marking this as Failed QA until it's fixed. That patch for the ISBN normalizing was throwing the error if the record contained NULL for the isbn field. Kyle can explain/fix. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11441] Ability to globally remove authorities with no bibliographic record linked.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11441 Marjorie Barry-Vila changed: What|Removed |Added CC||marjorie.barry-v...@ccsr.qc ||.ca -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7425] Export Bibliographic Holdings fails if no item records attached
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7425 Elaine Bradtke changed: What|Removed |Added Version|3.6 |3.14 --- Comment #2 from Elaine Bradtke --- Koha 3.14.03 Further experiences with this problem. Exporting a subset of the catalog selected by item type produces 0 records (these are item types that do not have item records attached). Exporting the whole catalogue as MARC, with items attached fails, the resulting file appears to only contain biblios with items. None of the biblios without items were exported. If I export the whole catalogue without items attached, then it will export all the records. Testing the export as XML: Exporting a subset of records selected by item type still produces 0 records (these are item types that do not have item records attached. Exporting the whole catalog, with items attached produces the expected number of records. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11989] New: Holds Queue Scheduling
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11989 Bug ID: 11989 Summary: Holds Queue Scheduling Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: cbran...@cdalibrary.org QA Contact: testo...@bugs.koha-community.org CC: gmcha...@gmail.com It would be great to see a transfer schedule set in place so that Koha could take into account days where items are not transferred in and out of a library, and take that into consideration along with the cost matrix. Some libraries only do transfers 1 or 2 times a week, where others transfer 5-7 times a week, or even more. For example: Patron at Library A requests item On Monday: Library B has item, and is best suited according to the cost matrix. Library C has item, and is next best suited according to the cost matrix. What the cost matrix doesn't take into account is that Library B won't transfer any items out until Thursday. Library C transfers daily. So, what happens? The request goes to Library B's queue, and sits in a bin until Thursday. The patron doesn't get the item until Friday, or possibly Monday. However, if transfer days were taken into consideration, the patron could get the item from Library C in a day or two, and the item at Library B doesn't have to sit in a bin for a week. The queue needs to first look at what libraries are transferring, either that day, or the day before (depending on the time of day the holds are pulled and processed and when transfers are picked up), and of those libraries that are close to transfer, then be assessed by the cost matrix. Also, if an item isn't processed at that library (maybe they missed the window), it is reassessed the next day. Perhaps it didn't get pulled and scanned before transfers that day. Now another library might be a better candidate. Of course the transfer schedule, the buffer (how soon before transfer does the library become eligible), and daily reassessment should all be preferences to be set. Anyway, this would be a good addition to the holds queue system. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613
--- Comment #33 from Jonathan Druart ---
(In reply to Jacek Ablewicz from comment #29)
> and it tested just fine in that form ("Useles use: " warning aside). Looks
> like merging %$line with %order is 100% redundant (%$line is allways the
> superset of %$order).
Yes, you are right, sorry for that.
>
> > > 152 supplierid => $details->{'supplierid'},
> > Fixed.
>
> Not fully yet - vendor link still doesn't work; there is no 'supplierid' key
> in $details->{}, we have 'booksellerid' instead.
I amended the first patch, which introduced this mistake.
Thanks Jacek for your vigilance!
The last patch needs a signoff.
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 --- Comment #32 from Jonathan Druart --- Created attachment 26536 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26536&action=edit Bug 10613: FIX QA issues This patch fixes the following QA issue: FAILacqui/invoice.pl FAIL valid Useless use of private variable in void context -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 --- Comment #31 from Jonathan Druart --- Created attachment 26535 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26535&action=edit Bug 10613: FIX typo supplierid vs booksellerid GetInvoiceDetails returns a hashref with a key named booksellerid, not supplierid. The bookseller was not retrieved from the DB and the listincgst value was always false. Signed-off-by: Jacek Ablewicz -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 Jonathan Druart changed: What|Removed |Added Attachment #25889|0 |1 is obsolete|| Attachment #25890|0 |1 is obsolete|| Attachment #26529|0 |1 is obsolete|| --- Comment #30 from Jonathan Druart --- Created attachment 26534 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26534&action=edit Bug 10613: The gst rate is not correctly calculated on the invoice page. Test plan: Defined a gst rate on creating an order, receive it and check that all prices are correctly calculated. /!\ Behavior change function of supplier parameters (Include/Don't include tax for list prices and invoice prices) Notes: patch tested with Bug 11755 applied first; confirmed that: - price calculations are correct for all combinations of listincgst/invoiceincgst settings in the vendor record - unitprice (aka "Actual cost") is taken into account on the invoice page instead of rrp/ecost, like it should. Amended patch: Don't change the supplierid/booksellerid parameter. Signed-off-by: Jacek Ablewicz -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 Jonathan Druart changed: What|Removed |Added Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11563] Class noEnterSubmit no longer functioning
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11563
--- Comment #19 from Fridolin SOMERS ---
(In reply to Jonathan Druart from comment #18)
> (In reply to Fridolin SOMERS from comment #17)
> > But this class in actually only set on "input" elements :
> > $("fieldset.rows input").addClass("noEnterSubmit");
>
> No, the *last* patch does the following :
> -$("fieldset.rows input").addClass("noEnterSubmit");
> +$("fieldset.rows input,select").addClass("noEnterSubmit");
>
> :)
Ohh, sorry I had not seen this patch.
@Kyle :
I think the JQuery selector is not correct :
$("fieldset.rows input,select").addClass("noEnterSubmit");
should be :
$("fieldset.rows input, fieldset.rows select").addClass("noEnterSubmit");
Also, the pages mancredit.tt and maninvoice.tt are also using noEnterSubmit
class. They should have the same JS code no ?
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11563] Class noEnterSubmit no longer functioning
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11563
--- Comment #18 from Jonathan Druart ---
(In reply to Fridolin SOMERS from comment #17)
> But this class in actually only set on "input" elements :
> $("fieldset.rows input").addClass("noEnterSubmit");
No, the *last* patch does the following :
-$("fieldset.rows input").addClass("noEnterSubmit");
+$("fieldset.rows input,select").addClass("noEnterSubmit");
:)
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613
Jacek Ablewicz changed:
What|Removed |Added
Status|Signed Off |Failed QA
--- Comment #29 from Jacek Ablewicz ---
(In reply to Jonathan Druart from comment #28)
> >FAIL valid
> > Useless use of private variable in void context
IMO
126: my %row = %{ $order, $line };
was actually a little better ;), being equivalent of:
my %row = %$line;
and it tested just fine in that form ("Useles use: " warning aside). Looks like
merging %$line with %order is 100% redundant (%$line is allways the superset of
%$order).
> > 152 supplierid => $details->{'supplierid'},
> Fixed.
Not fully yet - vendor link still doesn't work; there is no 'supplierid' key in
$details->{}, we have 'booksellerid' instead.
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11563] Class noEnterSubmit no longer functioning
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11563
--- Comment #17 from Fridolin SOMERS ---
(In reply to Jonathan Druart from comment #16)
> (In reply to Fridolin SOMERS from comment #11)
> > In this case, shall we add noEnterSubmit on select also ?
> > I think it does not impact other browser/OS combination.
>
> It is not what the last patch does?
No, this patch corrects behaviors for elements with "noEnterSubmit" class.
But this class in actually only set on "input" elements :
$("fieldset.rows input").addClass("noEnterSubmit");
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11723] Message "A refund has been applied" on all lost item returns
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11723 Jesse Maseto changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Severity|normal |enhancement -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11988] Display basket group close date on late orders
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11988 --- Comment #1 from Jonathan Druart --- Created attachment 26533 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26533&action=edit Bug 11988: Display aqbasketgroup.closeddate on late orders table Test plan: Display the late orders table and verify the basket group close date is correctly displayed. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11988] Display basket group close date on late orders
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11988 Jonathan Druart changed: What|Removed |Added Status|ASSIGNED|Needs Signoff -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11988] Display basket group close date on late orders
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11988 Jonathan Druart changed: What|Removed |Added Status|NEW |ASSIGNED Depends on||11708 Assignee|koha-b...@lists.koha-commun |jonathan.dru...@biblibre.co |ity.org |m -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11708] Display all basketgroups on one page, and new column aqbasketgroups.closeddate
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11708 Jonathan Druart changed: What|Removed |Added Blocks||11988 -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11096] Koha cannot retrieve big records from Zebra
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11096 --- Comment #78 from Katrin Fischer --- Hi Marcel, all my tests were done on a dev installation and it seemed to work ok there, but I didn't test the very last iteration I think. Can you give some more details about the problems you are facing? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11988] New: Display basket group close date on late orders
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11988 Bug ID: 11988 Summary: Display basket group close date on late orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs@lists.koha-community.org Reporter: jonathan.dru...@biblibre.com QA Contact: testo...@bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11096] Koha cannot retrieve big records from Zebra
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11096 M. de Rooy changed: What|Removed |Added CC||m.de.r...@rijksmuseum.nl --- Comment #77 from M. de Rooy --- I hope this patch will not cause a lot of trouble for non-package users. At least I am struggling now with getting dom indexing to work in master. In 3.14.4 [without this patch], it worked right away. I would not recommend to push this to stable too quickly. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11946] add table sorters to label and patron card batches
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11946 Owen Leonard changed: What|Removed |Added Status|ASSIGNED|Needs Signoff Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11946] add table sorters to label and patron card batches
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11946 --- Comment #1 from Owen Leonard --- Created attachment 26532 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26532&action=edit Bug 11946 - add table sorters to label and patron card batches When viewing batches of titles in the label creator module the table is not sortable. This patch adds table sorting. The patch also makes some corrections of invalid markup and moves informational/error messages to the top of the page rather than in a sidebar. This change lets the table and sorting controls expand into a wider space. To test, go to Tools -> Labels -> Manage label batches. View an existing batch or create a new batch and populate it with items. Table sorting controls should work correctly. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7679] Statistics wizard: circulation (new filters)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7679 paxed changed: What|Removed |Added CC||pasi.kalli...@pttk.fi --- Comment #31 from paxed --- (In reply to Julian Maurice from comment #29) > Created attachment 26531 [details] [review] > Bug 7679: Various fixes for circulation statistics wizard > > - use Text::Unaccent to remove accents from columns or rows values when > accessing %table. This is required as MySQL consider as equals two > strings that differ only by their accents when using GROUP BY clause. In some languages some of these "accented" letters are separate letters of the alphabet, and should not be "unaccented". For example, in Finnish, Ä (latin capital a with diaeresis) should not be turned into A. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7679] Statistics wizard: circulation (new filters)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7679 Julian Maurice changed: What|Removed |Added Status|Failed QA |Needs Signoff --- Comment #30 from Julian Maurice --- Hopefully, I easily reproduced your problems. This patch fixed them for me, so I hope it will work for you too :) -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7679] Statistics wizard: circulation (new filters)
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7679 --- Comment #29 from Julian Maurice --- Created attachment 26531 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26531&action=edit Bug 7679: Various fixes for circulation statistics wizard - use SQL TRIM functions to avoid having '' and ' ' considered as different values - use Text::Unaccent to remove accents from columns or rows values when accessing %table. This is required as MySQL consider as equals two strings that differ only by their accents when using GROUP BY clause. - Exclude '' values from the list of columns or rows. Otherwise we could have a row 'UNKNOWN VALUE' and a row 'NULL' which both have the same values in their cells. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7939] Separate po files for different MARC dialects
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7939 --- Comment #3 from Bernardo Gonzalez Kriegel --- (In reply to Magnus Enger from comment #0) > I think it would be a good idea to have separate po files for MARC21, > UNIMARC and NORMARC (value builders and XSLT). > > See also Bug 7934. Hi Magnus, do you want to try? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7939] Separate po files for different MARC dialects
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7939
--- Comment #2 from Bernardo Gonzalez Kriegel ---
Created attachment 26530
-->
http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26530&action=edit
Bug 7939 - Separate po files for different MARC dialects
[PRELIMINAR - not in final form but can be tested]
This patch implements separate PO files for
different MARC dialects.
To do so it depends on correct filenames,
i.e. it will build PO files using files
with/without "unimarc|normarc|marc21" on
their names.
Prominent changes:
A) tmpl_process3.pl
three new options: exclude or include certain filenames
and a new source dir that can have multiple values
B) LangInstaller.pm
added definitions to create or update nn-NO-{MARCFLAVOR}.po
and a little modification on install procedure
C) Standarization of filenames
OPAC prog po file is now xx-YY-opac-prog.po
STAFF po file is now xx-YY-staff-prog.po
MARC dialects po files are xx-YY-marc-{MARCFLAVOUR}.po
To test:
1) Update po files for your preferred language, ej. nn-NO
cd misc/translator
perl translate update nn-NO
(do it twice if there are warnings)
2) Do some copying/renaming
cp po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-marc-UNIMARC.po
cp po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-marc-NORMARC.po
cp po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-marc-MARC21.po
mv po/nn-NO-i-staff-t-prog-v-3006000.po po/nn-NO-staff-prog.po
mv po/nn-NO-i-opac-t-prog-v-3006000.po po/nn-NO-opac-prog.po
(most MARC dialect strings are on staff)
3) Apply the patch
4) Update again to fix translation files, verbose
perl translate update nn-NO -v
5) Install language, verbose, verify translations
perl translate install nn-NO -v
More tests to come.
To be continued...
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613
--- Comment #28 from Jonathan Druart ---
(In reply to Katrin Fischer from comment #24)
> FAIL acqui/invoice.pl
>FAIL valid
> Useless use of private variable in void context
(In reply to Jacek Ablewicz from comment #25)
> 152 supplierid => $details->{'supplierid'},
>
> is indeed not; as a result, link via "Vendor: " name is leading to nowhere.
> Which I should've spotted before signing-off :(.
Good catches!
Fixed.
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
Koha-bugs@lists.koha-community.org
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 --- Comment #27 from Jonathan Druart --- Created attachment 26529 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=26529&action=edit Bug 10613: FIX QA issues This patch fixes the following QA issue: FAILacqui/invoice.pl FAIL valid Useless use of private variable in void context It fixes also the booksellerid variable (supplierid is not used anymore in the template). -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 10613] Gst is not calculated correctly on the invoice page
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10613 Jonathan Druart changed: What|Removed |Added Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 7939] Separate po files for different MARC dialects
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7939 Bernardo Gonzalez Kriegel changed: What|Removed |Added CC||bgkrie...@gmail.com Assignee|frede...@tamil.fr |bgkrie...@gmail.com -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11232] Retrieve facets from Zebra
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232 --- Comment #30 from Paul Poulain --- (In reply to David Cook from comment #29) > PS Is that your way of saying that you're working on this project, Tomas? ;) For now, he's honeymooning ;-) (should be back around april, 15th) > I imagine it would be useful to write something a bit abstract for getting > facets, so that we can make it easier to plugin other indexers like Solr and > ElasticSearch... Of course ! -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 11985] Auto insert MARC 005 (Date and Time of Latest Transaction) detail when saving new catalog record
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11985 --- Comment #1 from M. de Rooy --- Did you see bug 5374? Check the code in ModBiblioMarc.. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
