[Koha-bugs] [Bug 34793] We should ship default 'CookieConsentPopup' data that describes our required cookies
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34793 --- Comment #10 from David Nind --- I've tested and am happy to sign off. Comments/suggestions: 1. Should the cookie bar link to the cookie policy? I only see this in the OPAC by going to Your account > Consents > under Cookies policy is "View your cookie consents" button > pop up window has "Accept all cookies" irrespective of whether you have clicked on the "Accept all cookies" in the cookie bar. 2. The table in the Consent policy page in the OPAC. It looks fine when you preview in Tools. However, in the OPAC it has hard to read as the rows are aligned to the center, with no alternate row colours or border between rows. Can the table rows be aligned to the top, and formatted similar to the staff interface tools preview? 3. I'm not sure that I understand the normal workflow for this from a patron perspective, even after reading through bug 27378, and how it works with the privacy policy. Testing notes: 1. Starting the web installer in KTD: https://gitlab.com/-/snippets/1893788#user-content-starting-the-web-installer -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://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 31074] Cached plugin code is used in Koha even after changes to plugin (install/upgrade/uninstall)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31074 --- Comment #43 from Victor Grousset/tuxayo --- (In reply to Martin Renvoize from comment #26) > Adding this here for reference so I don't forget.. we might be able to use > https://perldoc.perl.org/functions/getppid to find the Starman master pid.. > I'm going to run a few tests using that technique. Yep, it works. `getppid()` got me the PID of the master process. (check from the container if you use one. I didn't know between a docker container and the host, the PIDs would change) -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://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 31074] Cached plugin code is used in Koha even after changes to plugin (install/upgrade/uninstall)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31074 Victor Grousset/tuxayo changed: What|Removed |Added Severity|enhancement |normal --- Comment #42 from Victor Grousset/tuxayo --- (In reply to David Cook from comment #41) > Overall, if folk want to keep going down this path, then by all means they > should. All I would ask is that they have a configuration option for it in > koha-conf.xml which defaults to off. No correctness by default when managing plugins from the UI? (and oops, I created the ticket as enhancement when it's in fact about fixing bugs) And before the default value, why needing a way to disable it? What's the remaining issues? If an instance has plugins UI enabled, then in which case is that a problem that on plugin install/upgrade/uninstall, a reload is triggered? It seems and in every case, even in unsupported ones, there will be always a reasonable number of workers linked to an intance vs the number of threads so reload time shouldn't be too high. Should the plugin UI warn that install/upgrade/uninstall operation shouldn't be done on peak load. Because yes, that's the times even reasonable request stalls are not a good idea. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://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 35310] Current renewals 'view' link doesnt work if renewals correspond to an item no longer checked out
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35310 Victor Grousset/tuxayo changed: What|Removed |Added Status|Signed Off |In Discussion -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://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 35310] Current renewals 'view' link doesnt work if renewals correspond to an item no longer checked out
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35310 --- Comment #21 from Victor Grousset/tuxayo --- (In reply to Katrin Fischer from comment #18) > I already suggested how to fake it: > > (In reply to Katrin Fischer from comment #16) > > I think in testing we need to make sure that there is no regression when > > there are no entries in the table, but the renewals count on the checkout is > > > 0 (maybe also needs a last renewed date if you are faking the data). > > In issues:Ö increment the number in renewals_count and add a lastreneweddate. I see, because the old data isn't migrated due to missing date, it's left here and all places might need to account for two sources of renewals. So how should it be accounted here? After more testing of the current patches: - Item details page of a record doesn't show "Current renewals:" if there are only legacy renewals. - Item details page of a record and the modal only count stuff from checkout_renewals. But patron circulation history counts them all. Back to the root, if I understand correctly: that transient state that happens only when an instance just migrated causes to **either** 1. have (**temporary**) inconsistency in various places (if it affects circ history, inconsistency it lasts a long as personal data retention delay of the library) 2. add complexity in various places to account for two sources of renewal numbers 3. have this complexity put in a single place in the model layer 4. actually migrate the old data in checkouts_renewals even if with no renewal date. Does the way old data was let in issues.renewals_count means that the current strategy is to not bother with temporary inconsistency after migration? Then, current patches here are in line with that. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://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 35366] New: Circulation history of patron is only visible when there is a current checkout
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35366 Bug ID: 35366 Summary: Circulation history of patron is only visible when there is a current checkout Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: vic...@tuxayo.net QA Contact: testo...@bugs.koha-community.org CC: gmcha...@gmail.com, kyle.m.h...@gmail.com === test plan === 1. do a checkout 2. looks a circulation history of the patron, it's here 3. check in 4. history gets empty 😮️ 5. do a checkout 6. history now shows the two checkouts 😮 History in OPAC is ok. -- 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 https://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/
