[Koha-bugs] [Bug 11043] New: rename biblioitems.itemtype
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11043 Bug ID: 11043 Summary: rename biblioitems.itemtype Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: gmcha...@gmail.com Reporter: mathieu.s...@univ-rennes2.fr QA Contact: testo...@bugs.koha-community.org I find biblioitems.itemtype confusing. In discussions about itemtypes, I often had to ask which kind of itemtype it was about : biblioitems.itemtype or items.itype. It is an other issue, but zebra conf is confusing too, as in MARC21 the fields mapped with biblioitems.itemtype and items.itype are mapped with the same zebra index, whereas in UNIMARC 2 different indexes are used (biblioitems.itemtype = 099t = ccode index ; items.itype = 995r = itype index) I think it is not normal, and should be fixed in an other bug. biblioitems.itemtype is not about item, but about document, so what I would propose here is to rename biblioitems.itemtype to biblioitems.doctype or maybe biblioitems.kohadoctype (as document type can also be retreived from MARC fields non specific to Koha, like 210$b in UNIMARC) Any opinions? -- 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 #14 from mathieu saby mathieu.s...@univ-rennes2.fr ---
Hi
Nice enh
Tested on sandbox 1
* Test of Sort by hours: seems OK
Period From 03/09/2013
Period To 04/09/2013
Library = MAURES
Home branch = MAURES
Holding branch = MAURES
Event = issue
Display by = 4
datetime / itemtype Compact Disque Livre audio Livre Revue
TOTAL
9 0 0 0 1 0 0 1
10 0 0 0 2 0 0 2
11 0 0 0 3 0 0 3
In database :
2013-09-03 09:45:23MAURES0.issue5464LIVR
6068
2013-09-03 10:57:34MAURES0.issue4862LIVR
7570
2013-09-03 10:57:44MAURES0.issue1338LIVR
7570
2013-09-03 11:19:39MAURES0.issue5663LIVR
3488
2013-09-03 11:29:47MAURES0.issue2171LIVR
3431
2013-09-03 11:39:31MAURES0.issue4350LIVR
5212
* test of flter by itemtype : seems ok (same kind of test)
* test of patron attribute filter :
- display all checkouts between 01/08/2013 and 04/09/2013 ; dates in columns ;
professions in rows
= I did not check database, but presentation of results seemed ok :
agent administratif 0 0 0 0 0 0 0 0 0 0
0
agent d'accueil 0 0 0 0 0 0 0 0 0 0
0
enfant 0 0 1 0 0 0 0 0 0 0 1
Enseignant 0 0 1 0 0 0 0 0 0 0 1
etc.
- use a value of attribute Profession as a filter : value Enseignant
display only one line = ok
PROFESSION / datetime 9 10 11 12 13 14 15 16
17 18 TOTAL
Enseignant 0 0 1 0 0 0 0 0 0 0 1
TOTAL 0 0 1 0 0 0 0 0 0 0 3
But, at that point, I remarked a bug :
TOTAL is wrong : the last column is displaying 3, while the last column for
the only row ('Enseignant') is 1.
So, for Koha, the sum of 1 is 3. Wrong somewhere
Other remarks (cosmetic)
I think Item type should be better understood if named Document type. That
make obvious that is using biblioitems.itemtype (I suppose so?) and not
items.itype.
In the results, the Display by = [1...4] line is not easy to understand. It
seems that each number match a kind of date grouping (hours, months...). Could
you display it in plain english?
Could you check the calculation of TOTAL line?
M. Saby
--
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 mathieu saby mathieu.s...@univ-rennes2.fr changed: What|Removed |Added Status|Needs Signoff |Failed QA --- Comment #15 from mathieu saby mathieu.s...@univ-rennes2.fr --- (in fact, tested on sandbox 3, with radio button Count total items ) M. Saby -- 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 10844] circs by dewey range
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10844 mathieu saby mathieu.s...@univ-rennes2.fr changed: What|Removed |Added CC||mathieu.saby@univ-rennes2.f ||r --- Comment #2 from mathieu saby mathieu.s...@univ-rennes2.fr --- Here we created a SQL function for that. Mathieu -- 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 6030] Allow for html in letters in overdue notices
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6030 mathieu saby mathieu.s...@univ-rennes2.fr changed: What|Removed |Added CC||mathieu.saby@univ-rennes2.f ||r --- Comment #57 from mathieu saby mathieu.s...@univ-rennes2.fr --- I'm a big lost. Is this bug for 3.8.x or for master ? Mathieu -- 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 7421] UNIMARC authorities DOM indexing mode
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421 Galen Charlton gmcha...@gmail.com changed: What|Removed |Added Status|In Discussion |Passed QA --- Comment #56 from Galen Charlton gmcha...@gmail.com --- (In reply to mathieu saby from comment #55) (In reply to Galen Charlton from comment #54) (In reply to Katrin Fischer from comment #51) I am not sure if it's annoying - I always tell people that everything that is indexed can be searched in keyword search and the reactions so far are quite positive. I agree -- it's easier to explain that an any index includes everything (though whether or not fixed fields should be included is a matter of opinion), so I for one don't really see a problem with the change in behavior of the any index. Note, though, that that's a separate question from whether the any index should be included in, say, auth_finder.pl, as somebody looking for authority records via that interface has little reason to be using anything other than the headings searches to begin with. Sorry, but I do not agree with both of you. I'm speaking here in general, not for authorities (we don't give access to authorities on opac). The OPAC search with GRS1 is very noisy, with a lot of unwanted and non understandable results. Ex : I have a book published in Roma. It has 1 vol. (215 p.), it is written in french (fre in 105a) with an item having an INTERNAL note (not shown on opac) in 995 field, like book given by a teacher. This book will currently show on opac when some user search vol, fre, book, given, teacher or Roma. For Roma I could maybe understand, but I don't like that. For the other points I don't like that AT ALL. We have a rather big catalog (400 000 records), to Koha can easily find a lot of unrelated records for any search. With DOM I understand it will be worse. Of course this issue could been less problematic, if Koha had a good pertinence sorting (it is mad), a good date sorting (it is broken, for unimarc at least), and a good facetting system (all we have are pseudofacets, non parametrable for the moment, based only on the X first results, not cumulable, and whose general presentation is not user friendly). We can work on these points, of course, but it would be easier to define a more reasonable any index. These are reasonable concerns and coments, but IMO they are more for bug 8962 than this one. Since the immediate concern of this bug -- adding an initial DOM configuration for UNIMARC authorities -- is now addressed in master and we have an explanation of the differences in Any authority searches in DOM vs. GRS-1, I'm setting this one to pushed to master. -- 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 7421] UNIMARC authorities DOM indexing mode
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7421 Galen Charlton gmcha...@gmail.com changed: What|Removed |Added Status|Passed QA |Pushed to Master -- 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/
