[Koha-bugs] [Bug 15630] Make Edifact module pluggable
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15630 --- Comment #13 from David Cook --- Comment on attachment 49788 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=49788 Bug 15630 - Make Edifact module pluggable Review of attachment 49788: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=15630&attachment=49788) - ::: Koha/Plugins.pm @@ +20,4 @@ > use Modern::Perl; > > use Module::Load::Conditional qw(can_load); > +use Module::Pluggable search_path => ['Koha::Plugin'], except => > qr/::Edifact(|::Line|::Message|::Order|::Segment|::Transport)$/; This seems suboptimal... since any plugin with additional packages would need an exception. Wouldn't it make more sense to use "only" to only find plugins like ^Koha::Plugin::Com::CompanyName::PluginName$. I suppose it might be too late for that now as there's any number of plugins that can be allowed so perhaps one does have to only use exceptions from now on... I'm thinking of making a plugin, but I'll probably just use a different namespace like Local::PluginName::Submodules... -- 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 16540] Translatability in opac-auth.tt (tag-splitted sentences)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16540 Srdjan Jankovic changed: What|Removed |Added Attachment #51776|0 |1 is obsolete|| --- Comment #4 from Srdjan Jankovic --- Created attachment 51911 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51911&action=edit [SIGNED-OFF] Bug 16540: Translatability in opac-auth.tt (tag-splitted sentences) This patch removes tag-splitting from 2 sentences in pac-auth.tt To test: - Review code changes and verify that following sentences are no longer splitted by -tags: "Logout and try again with a different user" "Try to log in using a different Google account" UPDATE: Amended to fix a tiny typo Signed-off-by: Srdjan -- 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 16540] Translatability in opac-auth.tt (tag-splitted sentences)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16540 Srdjan Jankovic changed: What|Removed |Added Status|Needs Signoff |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 16609] Catch warning from Koha::Hold in Hold.t
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16609 Srdjan Jankovic changed: What|Removed |Added CC||srd...@catalyst.net.nz --- Comment #2 from Srdjan Jankovic --- That test is failing for me with DBD::mysql::st execute failed: Field 'lowestPriority' doesn't have a default value [for Statement "INSERT INTO `reserves` ( `biblionumber`, `borrowernumber`, `branchcode`, `itemnumber`, `suspend`, `waitingdate`) VALUES ( ?, ?, ?, ?, ?, ? )" with ParamValues: 0='6644', 1='386', 2='EP3', 3='19635', 4=0, 5='2000-01-01'] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1834. DBIx::Class::Storage::DBI::_dbh_execute(): Field 'lowestPriority' doesn't have a default value at Koha/Object.pm line 109 -- 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 16582] t/Price.t test should pass if Test::DBIx::Class is not available
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16582 Srdjan Jankovic changed: What|Removed |Added CC||srd...@catalyst.net.nz --- Comment #5 from Srdjan Jankovic --- Just a couple of generic questions/musings not entirely to do with this patch: * Wouldn't it be better to rename tests that we don't want to .t.NOT_READY_YET or similar instead of doing those regexes in load.t? * I don't understand why use_ok are in the BEGIN block? * maybe (if not too much of a hassle) we could leave use_ok for Test::DBIx::Class dependant tests, and skip the rest? -- 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 16582] t/Price.t test should pass if Test::DBIx::Class is not available
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16582 --- Comment #4 from Srdjan Jankovic --- Created attachment 51910 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51910&action=edit [SIGNED-OFF] Bug 16582 t/Price.t test should pass if Test::DBIx::Class is not available TEST PLAN - 1) prove t/Prices.t -- failure 2) apply patch 3) prove t/Prices.t -- nicely skipped when Test::DBIx::Class is not available. Signed-off-by: Srdjan -- 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 16582] t/Price.t test should pass if Test::DBIx::Class is not available
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16582 Srdjan Jankovic changed: What|Removed |Added Status|Needs Signoff |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 16582] t/Price.t test should pass if Test::DBIx::Class is not available
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16582 Srdjan Jankovic changed: What|Removed |Added Attachment #51758|0 |1 is obsolete|| Attachment #51759|0 |1 is obsolete|| --- Comment #3 from Srdjan Jankovic --- Created attachment 51909 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51909&action=edit [SIGNED-OFF] Bug 16582 t/Price.t test should pass if Test::DBIx::Class is not available This patch makes it so 00-load.t doesn't cause 'prove t' to prematurely die before reaching other tests. TEST PLAN - 1) prove t -- dies on 00-load.t 2) apply patch 3) prove t -- now t/Prices.t should be the failure. Signed-off-by: Srdjan -- 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 16575] Irregular behaviour using window.print() followed by window.location.href=
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 Srdjan Jankovic changed: What|Removed |Added CC||srd...@catalyst.net.nz --- Comment #4 from Srdjan Jankovic --- I think you should have included js removal with the patch, not used so should go. What's the story with the intranet basket? -- 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 16575] Irregular behaviour using window.print() followed by window.location.href=
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 Srdjan Jankovic changed: What|Removed |Added Attachment #51907|0 |1 is obsolete|| --- Comment #3 from Srdjan Jankovic --- Created attachment 51908 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51908&action=edit [SIGNED-OFF] Bug 16575 - Irregular behaviour using window.print() followed by window.location.href= Use print.css for OPAC basket when printing instead of using navigation. Currently, when you click "Print" on the OPAC basket, it'll navigate to a new page and initiate window.print() followed by a window.location.href change again. Unfortunately, due to differences in IE, Chrome, and FF, it will either show the print options, navigate away without showing them, or refuse to navigate away after printing. By changing to using print.css, we don't navigate away from the basket in the first place, so we prevent this irregular behaviour. _TEST PLAN_ 1) Apply the patch 2) Create an OPAC basket by clicking "Add to cart" on multiple items 3) Using Chrome, IE, and Firefox (of any version), click the "Print" button 4) You should see the relevant print menu without the OPAC basket re-loading in any way. 5) After printing is complete, you should still be on the OPAC basket pop-up Signed-off-by: Srdjan -- 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 16575] Irregular behaviour using window.print() followed by window.location.href=
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 Srdjan Jankovic changed: What|Removed |Added Status|Needs Signoff |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 16574] Software error when search the catalog
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16574 --- Comment #8 from David Cook --- (In reply to Janice Chow from comment #7) > Hi David, > > I got total 649 records in my database and I using MARC21. > > I through the data problem should be what I input on 23/5. Since I inputted > and I can't search the word "csj", "journal" etc... Should I delete this > MARC record? > > Thank you. I'm not sure what you mean by 23/5, but if you know which record is causing the problem, I would suggest deleting it. You'd probably want to save/export it first so that you can re-import the record's data in again later. I would recommend trying this tool plugin: https://github.com/bywatersolutions/koha-plugin-marc-checker It might help to find problems with your 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 16575] Irregular behaviour using window.print() followed by window.location.href=
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 --- Comment #2 from David Cook --- At some point, it would be prudent to strip the now unnecessary "print_basket" stuff out of opac-basket.tt. I didn't include it here, as it wasn't necessary for the actual bug fix. I also didn't want to do the work of removing all that code, if QA decides that this fix is no good, so I'm happy to add a follow-up once QA is happy with this 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 16575] Irregular behaviour using window.print() followed by window.location.href=
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 David Cook 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 16575] Irregular behaviour using window.print() followed by window.location.href=
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16575 --- Comment #1 from David Cook --- Created attachment 51907 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51907&action=edit Bug 16575 - Irregular behaviour using window.print() followed by window.location.href= Use print.css for OPAC basket when printing instead of using navigation. Currently, when you click "Print" on the OPAC basket, it'll navigate to a new page and initiate window.print() followed by a window.location.href change again. Unfortunately, due to differences in IE, Chrome, and FF, it will either show the print options, navigate away without showing them, or refuse to navigate away after printing. By changing to using print.css, we don't navigate away from the basket in the first place, so we prevent this irregular behaviour. _TEST PLAN_ 1) Apply the patch 2) Create an OPAC basket by clicking "Add to cart" on multiple items 3) Using Chrome, IE, and Firefox (of any version), click the "Print" button 4) You should see the relevant print menu without the OPAC basket re-loading in any way. 5) After printing is complete, you should still be on the OPAC basket pop-up -- 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 16574] Software error when search the catalog
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16574 --- Comment #7 from Janice Chow --- Hi David, I got total 649 records in my database and I using MARC21. I through the data problem should be what I input on 23/5. Since I inputted and I can't search the word "csj", "journal" etc... Should I delete this MARC record? Thank you. -- 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 16376] Koha::Calendar->is_holiday date truncation creates fatal errors for TZ America/Santiago
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16376 David Cook changed: What|Removed |Added Attachment #51702|0 |1 is obsolete|| --- Comment #15 from David Cook --- Created attachment 51906 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=51906&action=edit Bug 16376 - Koha::Calendar->is_holiday date truncation creates fatal errors for TZ America/Santiago Using a DateTime object with a timezone of America/Santiago was causing fatal errors for Koha::Calendar->is_holiday and Koha::Calendar->exception_holidays, when the objects were truncated to an invalid local time. Using a floating zone allows us to use the same day, month, year for comparison purposes without running into the possibility of creating an invalid local time and thus a fatal software error. -- 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 16376] Koha::Calendar->is_holiday date truncation creates fatal errors for TZ America/Santiago
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16376
--- Comment #14 from David Cook ---
(In reply to Jonathan Druart from comment #12)
> Moreover `grep time_zone Koha/Calendar.pm` will return another occurrence
> where the fix should be applied too.
Interesting.
I think I avoided that the first time because $calendar->is_holiday() uses the
following:
my $ymd = $localdt->ymd('') ;
if ($self->single_holidays( $ymd ) == 1 ) {
return 1;
}
However, you are correct. sub single_holidays is weird... but definitely prone
to this problem too.
--
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 16574] Software error when search the catalog
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16574 --- Comment #6 from David Cook --- By the way, since this looks like a data issue, it would probably be more appropriate and useful to discuss this on the listserv: http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel -- 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 16574] Software error when search the catalog
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16574 --- Comment #5 from David Cook --- Janice, I'm guessing the problem is your data. How many records do you have in your database? Are you using MARC21 or UNIMARC? -- 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 16376] Koha::Calendar->is_holiday date truncation creates fatal errors for TZ America/Santiago
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16376 --- Comment #13 from David Cook --- (In reply to Jonathan Druart from comment #11) > Ok you will remove the software error, but I am not sure it's the way to go. > I would certainly prefer a more thorough overhaul of Koha's DateTime handling, but I think this is good enough for now. Chile can't use the overdue functionality in Koha at all at this stage without this fix. > Currently the dates are stored in local time (so with the tz), if we want to > switch to floating time zones (what we should do at some point!) I think we > should recalculate all dates present in DB. > An easy workaround would be to use Koha::DateUtils, which deals (at least > try to) with invalid dates due du DST. Well, we calculate and interpret the dates using local time, but they're stored without timezone in the database. So I'm not sure what you mean by "recalculate all dates present in DB". The only difference between "local" and "floating" is the timezone. They're the same numbers, so there would be no recalculation to do. Or do you mean we should recalculate into UTC? Even if it were stored in UTC, it would need to be converted to local, and then to floating for the actual date handling, as we'd need the local numbers before doing any datetime math/truncation for the holiday checks. I have my reservations about Koha::DateUtils... I don't think enough thought has been put into its implementation. Besides, it wouldn't work in this case. Jonathan, the main problem at the moment is that Koha::DateUtils produces a valid local time, so it uses the local timezone. During the $calendar->days_between(), a day is added to this local datetime to produce another valid local time. However, the act of truncating that valid local time creates an invalid local time. So Koha::DateUtils isn't going to know there's a problem until it's too late. You could implement your own wrapper around DateTime, but I think that's getting excessive. We just need to be thoughtful and careful in our handling of dates and time. -- 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 16583] Strangeness in the staff client on ubuntu 16.04 and MySQL 5.7
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16583 Bernardo Gonzalez Kriegel changed: What|Removed |Added CC||bgkrie...@gmail.com --- Comment #1 from Bernardo Gonzalez Kriegel --- Hi Liz, we'll have plenty of trouble with (In reply to Liz Rea from comment #0) > Have noticed some strangeness with a clean install of Koha on MySQL 5.7: we'll have plenty of trouble with 5.7 > > When adding a rule at /cgi-bin/koha/admin/smart-rules.pl, if any box is left > empty the first empty field pops an error similar to this: > > DBIx::Class::Storage::DBI::_dbh_execute(): Incorrect integer value: '' for > column 'chargeperiod' at row 1 at > /usr/share/koha/intranet/cgi-bin/admin/smart-rules.pl line 170 In this case the problem is that we depended on a type conversion done by MySQL, empty '' string -> 0. In smart-rules.pl for example, every empty box is sent as an empty string to the database, which used to transform that to 0. With 5.7+ version this is not the default behavior :( > > When attempting to add a borrower category, it thinks a duplicate has been > added with the resultant error message > > "An error occurred when inserting this patron category. The patron category > might already exist." > There are some cases where the strange use of 'GROUP BY' not really needed triggers the error. This is one of them. Thoughts: a) try to support the 'strict' mode of MySQL 5.7+ b) suggest that anyone interested reconfigure server to a less 'strict' mode c) ignore the problem because is not in Debian, yet. I've patches for these problems, and others not yet reported. Just need to know what are we going to do. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 15541] Prevent normalization during matching/import process
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15541 --- Comment #19 from David Cook --- (In reply to Marcel de Rooy from comment #18) > Could you (slightly) adjust the way to skip the normalize call for the URLs, > that does not suggest that the norms functionality is present while we do > not even have C4::Normalizer? I'm not sure that I understand your question... Regardless of whether or not you provide a value for "Normalization rule" on /cgi-bin/koha/admin/matching-rules.pl, the default _normalize() function will run. While the matchpoint_component_norms.norm_routine isn't currently used in the code, I add some code that does use it for the sole purpose of detecting a "none" or "raw" normalization (ie no normalization). Are you saying that you don't want me to add that code because it suggests to people that adding a value there (besides "none" or "raw") will have an effect? I could a checkbox on the UI that says "Skip normalization rule" or something like that, but it would fulfil the same purpose of adding a "none" norm_routine in the database. Sorry, but I'm still not sure what you're asking, Marcel. Honestly, there should probably be no normalization at this step. I would remove the "Normalization rule" from the code, but it affects too many existing systems. The patch I have here is the lightest change while also providing the desired functionality. I'm not sure what else a person could do to skip the normalization in a way that is backwards compatible. -- 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 16488] UNIMARC to MARC21 xslt to be used in z39.50 import sources
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16488 Manos PETRIDIS changed: What|Removed |Added CC||egpetri...@yahoo.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 14239] Bibframe support in Koha
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14239 Bob Birchall changed: What|Removed |Added CC||b...@calyx.net.au -- 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/
