May 2021 - Koha-bugs - lists.koha-community.org

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #330 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- (In reply to Martin Renvoize from comment #327) > (In reply to Jonathan Druart from comment #324) > > 5. Can you explain me what this rule means? > > > > | id | tag | module | filter | add | append | remove | delete | > > | 1 | 12 | source | batchmod | 1 | 0 | 0 | 0 | > > With 'batchmod', only add tag 12 is if exists only in the incoming record. I still don't understand, but I now see the manual stuff, will read it (haven't seen it before, sorry!) Note for myself: One another thing to check, how is working the "preview" for the batchmod. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #329 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- (In reply to Martin Renvoize from comment #327) > (In reply to Jonathan Druart from comment #324) > > 2. We don't hide the admin page if the pref is off, is that expected? > so they wanted to display the page regardless or whether the pref was on or off Make sense > (the page does warn you at the top if the pref is off) That's wrong, there is no warning. > > 3. Should we link the pref to the admin page? > > Not sure what you're saying here? Have a link to the admin page, next to the pref. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 --- Comment #58 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- Pushed to master for 21.05, thanks to everybody involved! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 Jonathan Druart <jonathan.druart+koha(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |21.05.00 released in| | Status|Passed QA |Pushed to master -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #328 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- OK, I did test this actually.. The modification templates are applied prior to save.. so the changes are then blocked by the rules here. The main thing I don't like about this bug is exactly what Andrew is highlighting.. at the moment it's all rather silent. It would be great as a followup early next cycle to enhance each of the area's it touched with feedback either during save or prior to it to let the end user know that their changes will not be applied due to the rules in place here. I felt that the base bug was already large and complicated and shouldn't be blocked any long as a bug in itself.. I'm really hoping that follow-up bugs will be acted on in a timely fashion.. even if it means me lending a hand. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #327 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- (In reply to Jonathan Druart from comment #324) > 1. See comment 321 Replied above > 2. We don't hide the admin page if the pref is off, is that expected? Whilst I agree with what you're saying here, I think if memory serves this was discussed earlier in the bug and the authors wanted the ability to create their rules and then enable them.. so they wanted to display the page regardless or whether the pref was on or off (the page does warn you at the top if the pref is off).. having said that.. I'd be happy to follow-up to change that.. or, in my opinion in a later bug we could drop the pref and instead have an 'enabled' flag at the rule level. > 3. Should we link the pref to the admin page? Not sure what you're saying here? > 4. We need a wiki page, or at least more info/examples for the release notes. > There is only 2 very succinct example in the test plan but the feature > allows much more. I agree, it took me a fair while to wrap my head around the rules.. I think a wiki page would be great and would be happy to start one. > 5. Can you explain me what this rule means? > > | id | tag | module | filter | add | append | remove | delete | > | 1 | 12 | source | batchmod | 1 | 0 | 0 | 0 | With 'batchmod', only add tag 12 is if exists only in the incoming record. > 6. How does it interface with the marc modification templates when batch > editing bibliographic records? Investigating.. I have a feeling his patchset predates it and I missed this case ! :( -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #326 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- (In reply to Jonathan Druart from comment #321) > Running `dbic` generates a change to Koha/Schema/Result/MarcOverlayRule.pm. > It removes a FK to Koha::Schema::Result::MarcOverlayRulesModule. > However this table does not exist. Should I drop the schema changes and > regenerate it properly or here is something else missing? I think drop the dbic patch here and use the regenerated one.. I think the Module bit got removed during the history of this bug but the schema didn't get regenerated. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28300] ZEBRA CRASHED & SEARCHING THE CATALOGUE RETURNS 0 RESULTS
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

1 0

[Bug 27778] New: Prevent tables overflowing their containers on patron accounts
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27778 Bug ID: 27778 Summary: Prevent tables overflowing their containers on patron accounts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The tables on the patron accounts page can easily overflow their borders at high zoom levels or on low resolution monitors. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 14957] Write protecting MARC fields based on source of import
by bugzilla-daemon＠bugs.koha-community.org 07 May '21

07 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14957 --- Comment #325 from Jonathan Druart <jonathan.druart+koha(a)gmail.com> --- 7. (In reply to Andrew Fuerste-Henry from comment #226) > I made this rule: > Module: source > Filter: * > Tag: 500 > Preset: Protect > > When I go to edit a record, there's nothing in the edit interface to suggest > my edits won't be saved. I can type in a new 500, click to delete an > existing 500, etc. When I save my edits, there's nothing to indicate that my > changes were discarded or why. The edits simply aren't saved. > > This lack of feedback seems really confusing. Still valid. However a new record can be created with a 500, is that expected? -- You are receiving this mail because: You are watching all bug changes.

1 0