December 2019 - Koha-bugs - lists.koha-community.org

[Bug 15496] Delete bibliographic record after moving last item to another record(s)
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15496 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |24232 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24232 [Bug 24232] Deleting a bib record after attaching the last item to another bib -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24188] New: Sorting AZ does not work
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24188 Bug ID: 24188 Summary: Sorting AZ does not work Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: team(a)gelinger.at QA Contact: testopia(a)bugs.koha-community.org Our client has the latest 19.11 Koha Installed. After search is done, and you change sorting to the Title A-Z or Z-A , it does not work. It's just random. The same applies to the Sorting by Author. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 7882] Add ability to move and reorder fields in MARC editor
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7882 --- Comment #56 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Owen Leonard from comment #53) > When I test this I am able to drag a tag but when I drop it it returns to > its original position. Dragging subfields works to re-order them, but after > I save the record the order is back to where it was before. Tested in > Firefox and Chrome on Windows 10. Hi Owen, The important bit is " => You can only change the order of fields of the same tag." That is always why I suggested to remove the sortable thing for those fields. For instance unique fields cannot be moved. > Dragging subfields works to re-order them, but after I save the record the order is back to where it was befor I do not see this issue. I can sort subfields, save, edit again => the subfields order is kept. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #20 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Sorry.. I don't think my question was clear.. I'm totally onboard with wanting to replace the workflow we have and having one update file which then followed the standard translations workflow we have elsewhere.. What I wasn't fully understanding is why we needed to move from a lots of SQL files to one YAML/XML/Whatever file instead of a single SQL file which gets translated via the tools. Sounds like SQL is just too hard to parse as is for the existing translation tools.. that's the answer. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #19 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Martin Renvoize from comment #17) > Going back to the actual problem this patchset is trying to resolve.. can > you remind me what it is about the SQL format files in the first place means > we can't easily support translating them without moving to some intermediary > file format? .sql files are not following the usual translation workflow. There is 1 file per language (in the term of language in installer/data/mysql/, so not so much compared to the number of languages we really support (POs). If you want to translate a sql file, you need to open a bug report, patch it, wait for someone to SO/QA/push. Also it's painful to support (dev POV), as if you want to add an AV, you have to edit X .sql files, test them, (rebase), etc. With only 1 sql file, at the root of installer dir (installer/data/mysq) the translation will be done using the usual workflow (after a change to our translator tool as we still do not support YAML file, but we do support .pref which are YAML, so should not be too hard) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #18 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- > Going back to the actual problem this patchset is trying to resolve.. can > you remind me what it is about the SQL format files in the first place means > we can't easily support translating them without moving to some intermediary > file format? I think the problem is that you can't 'mark' what needs translation. You only want to translate a small bit of the SQL files, the descriptions while preventing people to translate values that should not be changed. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #17 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Sorry Bernardo, I didn't mean to knock this one off the rails so much :(. Hmm, it's a shame SQL::Translator only handles definition... I must have misremembered... it's SQL::Abstract ( the the various DBIx::Class extensions) that does the rest. SQL::Abstract is Perl script however so may not be especially helpful here? As for DBIx::Class::Schema::Versioned, I'm really not sure I understand what that would win for us (especially as the general recommendation in DBIx::Class land now is not to use it, but rather use DeploymentHandler instead). Koha's installer is actually pretty powerful as it is in my opinion and this is just one minor area we can improve.. please highlight some problems you feel such a move would resolve? Going back to the actual problem this patchset is trying to resolve.. can you remind me what it is about the SQL format files in the first place means we can't easily support translating them without moving to some intermediary file format? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #16 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Bernardo Gonzalez Kriegel from comment #11) > (In reply to Jonathan Druart from comment #9) > > Hola Bernado, > > I like the idea, but not XML, neither the MySQL only limitation. > > Salut Jonathan, > I don't like XML either, nor the MySQL only. > Just remember that I was thinking in translations, and xml support it's > included right now. > But yaml can be handled. > > > Why not write our own stuff, yml-based? > > No problem, I'll write a POC patch, but have a question: > > Do you think the sequence > a) Read YAML > Write $tmp/out.sql > > DBIx_::RunSQL->run_sql_file($tmp/out.sql) > is a valid approach, or > b) Read YAML > Insert into DB somehow > it's better? > I suppose b) is slower. I would: - Retrieve and parse the whole YAML file - Generate the SQL queries (like 1 per table) - Execute the INSERT statements (using DBIx::RunSQL->run_sql) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #15 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I am not sure if XML is really easier to read here, but enabling translation would be great. :) I'd vote against 'compiling at release time'. If we still need to create SQL files and store them, we should do so continously like we do for CSS etc. as this needs to be testable with current data all the time. Please keep in mind when changing the web installer, that it's currently possible to add additional SQL files to the installer that will be picked up - it would be nice to keep that feature. There is also the option to have a syspref.sql for some additional settings (see de-DE installer) that not all languages have made use of. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13897] Use XML files for installer data
by bugzilla-daemon＠bugs.koha-community.org 17 Dec '19

17 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13897 --- Comment #14 from David Cook <dcook(a)prosentient.com.au> --- While we're on this topic, perhaps it's worthwhile talking about something like this: https://metacpan.org/pod/DBIx::Class::Schema::Versioned -- You are receiving this mail because: You are watching all bug changes.

1 0