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

[Bug 27906] New: Add support for circulation status 9 ( waiting to be re-shelved )
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27906 Bug ID: 27906 Summary: Add support for circulation status 9 ( waiting to be re-shelved ) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: About Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 28399] New: batchRebuildItemsTables.pl error 'Already in a transaction'
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28399 Bug ID: 28399 Summary: batchRebuildItemsTables.pl error 'Already in a transaction' Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: julien.sicot(a)univ-rennes2.fr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Hello, When I run misc/batchRebuildItemsTables.pl , I get the following errors : DBD::mysql::db begin_work failed: Already in a transaction at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1590. DBD::mysql::db begin_work failed: Already in a transaction at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1590. Seems an issue similar to bug #27245. Many thanks, Best, Julien Sicot Systems Librarian Rennes 2 university -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 15504] Track Patron's Last Activity
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 Bug 15504 depends on bug 28455, which changed state. Bug 28455 Summary: If TrackLastPatronActivity is enabled we should update 'lastseen' field on checkouts https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28455 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldstable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 28455] New: If TrackLastPatronActivity is enabled we should update 'lastseen' field on checkouts
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28455 Bug ID: 28455 Summary: If TrackLastPatronActivity is enabled we should update 'lastseen' field on checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #12 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- Okay, based on this discussion, we can simplify the scope of this project: * A new field (ie patron_read) will be added to the messages table to record that the patron has read the message. * If a message is set to display on the OPAC for the patron, the patron will have a 'Dismiss' or 'Mark as read' button next to the message. * When the patron marks the message as read, the new field (ie patron_read) will have the current date added to it, indicating the date that they read the message. * If this new field has a value (a date), it will no longer show on the OPAC. It will also display a label, such as 'Read xx-xx-xxxx', where x is the date in the field. (Date will need to be formatted to admin date settings.) This functionality will not delete the message. It will allow staff to see that the patron has read the message, and staff will still have the ability to delete the message at their discretion. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #11 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- > Oh, wait. I think I understand. So, if we flag the it as read by putting a > date in the new field, we just turn off visibility on the opac side. We > don't have to touch the message_type field at all. That makes sense. :) > Am I understanding correctly? Everything else should still work the same, > because we will still be able to see it on the staff side, and it will still > be flagged as read? Yep, exactly what I meant. This way we don't change the current logic, but just enhance it a bit further. Changing the display logic in the OPAC to filter by the new 'read flag' should not be too hard and it will be a little less disruptive for the current workflows. Also, if we needed to revert from read to unread or wanted to optionally show read messages again, that would be relatively easy, because we can still tell what messages are 'patron' messages. I like the idea of making the 'read flag' a date. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #10 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Owen Leonard from comment #9) > (In reply to Christopher Brannon from comment #7) > > > When a message is marked as B (patron), it is seen on BOTH sides, by patron > > and staff. Changing it to L (staff) would accomplish dismissing it on the > > patron side, and maintaining current workflows on the staff side. > > It's not necessary if we're using logic in the OPAC to hide any message > which is marked as seen. Oh, wait. I think I understand. So, if we flag the it as read by putting a date in the new field, we just turn off visibility on the opac side. We don't have to touch the message_type field at all. That makes sense. :) Am I understanding correctly? Everything else should still work the same, because we will still be able to see it on the staff side, and it will still be flagged as read? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #9 from Owen Leonard <oleonard(a)myacpl.org> --- (In reply to Christopher Brannon from comment #7) > When a message is marked as B (patron), it is seen on BOTH sides, by patron > and staff. Changing it to L (staff) would accomplish dismissing it on the > patron side, and maintaining current workflows on the staff side. It's not necessary if we're using logic in the OPAC to hide any message which is marked as seen. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #8 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- One small adjustment I would suggest, and should be easy enough, is to add the date of when the message was read to the label on the staff side. Perhaps the date could be the flag in the new field. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12029] Patrons should be able to delete their patron messages
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12029 --- Comment #7 from Christopher Brannon <cbrannon(a)cdalibrary.org> --- (In reply to Owen Leonard from comment #6) > (In reply to Katrin Fischer from comment #5) > > Why the change from B to L? > > I agree that this doesn't seem to be a necessary step. This step was added because the message system does not archive these messages. If the message were just deleted, there would be no easy way for staff to see that the patron acknowledged receiving the message. If it were marked and hidden, we would be retaining messages that would build up over time, and the table would have to be maintained. When a message is marked as B (patron), it is seen on BOTH sides, by patron and staff. Changing it to L (staff) would accomplish dismissing it on the patron side, and maintaining current workflows on the staff side. After this enhancement, staff would be able to KNOW that the patron has seen the message, and the staff could decide whether to keep or delete the message from that point. Right now, staff have NO idea if the message is seen, and therefore have no idea when it would be appropriate to delete, if desired. This workflow enhancement has the least impact on current practices while adding needed functionality, and adding information for staff to enhance their workflow with these messages. -- You are receiving this mail because: You are watching all bug changes.

1 0