Project

General

Profile

Spent time

Filters

Apply Clear

Hours: 344.53

Created Date User Activity Issue Comment Hours
27.09.2023 01:11 27.09.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Publishing the endeavour to the Koha-Community. Sharing the latest WIP code to github. 1.15 Actions
27.09.2023 03:29 27.09.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Engaging the community in IRC. Answering questions. 0.33 Actions
27.09.2023 16:56 27.09.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Reading the IRC buzz. 0.20 Actions
30.09.2023 01:01 30.09.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Discussing project continuity with the client. 0.33 Actions
04.10.2023 16:54 04.10.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Scheduling a meeting with PTFS-E and published it on the mauling list. Levitating on how awesome the RFC is. 0.50 Actions
04.10.2023 17:05 04.10.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Reading ISO18626 CILLT emails and meeting dates. 0.33 Actions
06.10.2023 17:07 06.10.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Meeting with PTFS-E. ashimema and Pedro present. Discussing ISO18626 and our clients needs. Identified challenges regarding the standard: how to know in advance what the cost of the ILL is? 1.00 Actions
06.10.2023 17:25 06.10.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Post-meeting ideas propagation. Asking clarifications from PTFS-peeps. Emailing NatLibFi about meeting notes and discoveries and CILLT ISOILL about the new discovered challenges with the standard. 1.45 Actions
07.10.2023 17:40 07.10.2023 Olli-Antti Kivilahti Design Support #1101: ISO ILL 18626 ja Koha - Design phase. Started work on documenting the actual technical differences between those two approaches. There is a lot of overlap anyway. 1.22 Actions
07.10.2023 21:49 08.10.2023 Olli-Antti Kivilahti Design Support #1101: ISO ILL 18626 ja Koha - Design phase. Hands-on installed Koha-to-Koha ILL plugin from ByWater solutions and testing on how everything work and is rendered. Got a better outlook than from plain code-review. Documenting challenges with the Koha::ILL-approach, but Koha::ILL approach is the fastest way to get started and it is easy to just modify existing examples. 4.11 Actions
25.10.2023 14:35 25.10.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. ISO18626 Authentication Recommendations and Best Practices -meeting with all the big shots. Commenting intensely on auth mechanisms. Reviewing proposed OAuth2 guidelines. Looks good and nice. 1.80 Actions
06.11.2023 14:42 06.11.2023 Olli-Antti Kivilahti Communication Support #1101: ISO ILL 18626 ja Koha - Design phase. Asking KK for a status update. 0.20 Actions
01.12.2022 15:14 01.12.2022 Lari Taskula Design Feature #994: REST API: GET deletedborrowers Received a contact from possible client requesting REST API endpoints for listing added, modified and deleted patrons. Returning an estimation and making a quick design for how the endpoints could look. Investigating current endpoints further - it's actually already possible to use current patron endpoint for listing added and modified patrons with the contact's needs. Reporting findings to our contact. 2.00 Actions
28.11.2022 22:30 29.11.2022 Lari Taskula Development Support #993: Bug 32357 - Set borrower_message_preferences.days_in_advance default to NULL Investigating SetMessagingPreferences logic. It seems it overrides borrower_message_preferences.days_in_advance default (from 0 to null), so we might as well set default to null at database level. Implementing patch, figuring out how to test it, commenting on Bugzilla, attaching a patch. 1.50 Actions
10.11.2022 04:57 10.11.2022 Lari Taskula Development Support #973: Bug 18595 - Move C4::Members::Messaging to Koha namespace Rebasing. Git conflicts resolved mostly without pain. There seems to be new appearances of usage of the methods this Bug aims to replace. They have to be identified, replace with the new methods and amend test plan to cover these cases. Identifying all new occurences and replaced them with new methods. Debugging some failed unit tests, especially t/db_dependent/api/v1/patrons.t. Deeper investigation revealed some issues. Firstly, days_in_advance must be explicitly defined as undef, because Koha has defined default days_in_advance value to be 0 at database level. It is easy to explicitly define it but at the same time it is also pointless to do so and such cases should be handled inside Koha objects. Did not yet implement such checks. Secondly, it seems the new objects do not return letter_code and letter_module which are required by the test, and the test will fail with the current logic. Studying what the current options are to resolve this issue. 4.00 Actions
29.11.2022 00:40 29.11.2022 Lari Taskula Maintenance Support #973: Bug 18595 - Move C4::Members::Messaging to Koha namespace Rebasing Bug 18595, fixing tests. 2.00 Actions
29.11.2022 13:40 29.11.2022 Lari Taskula Development Support #973: Bug 18595 - Move C4::Members::Messaging to Koha namespace Testing patches, found errors with patch "Catch message preference exceptions in OPAC", wrong exception package name, probably due to previous rebasing mistake. Fixing. 1.00 Actions
30.11.2022 18:24 30.11.2022 Lari Taskula Maintenance Support #973: Bug 18595 - Move C4::Members::Messaging to Koha namespace Going through test plans, found a 500 error in staff client when creating a new patron and email is not set. This was in fact already reported in 18595, but I had forgotten it. Need better exception handling in staff client. 1.00 Actions
30.11.2022 18:52 30.11.2022 Lari Taskula Development Support #973: Bug 18595 - Move C4::Members::Messaging to Koha namespace Thinking of possible solutions to the previous issue with missing contact information at patron creation step. First, attempting to catch exceptions at memberentry.pl and display an error message. This doesn't work however due to incompatible error handling in memberentry.pl. Remembered an old solution, a JavaScript validation that I've already implemented before. This could be an approach for resolving the issue. Found my old work from 2015 (Bug 14590) to which we can use here. Restoring old code from the patch in 14590 and rebasing it on current master. Testing changes, seems to work. Continuing testing rest of the test plans, preparing test plans and patches for attaching. 4.00 Actions
06.10.2022 12:07 06.10.2022 Lari Taskula Maintenance Support #972: Bug 17499 - Koha objects for messaging preferences Rebasing Bug 17499 and attaching fresh patches to Bugzilla. 1.00 Actions
06.10.2022 13:22 06.10.2022 Lari Taskula Communication Support #972: Bug 17499 - Koha objects for messaging preferences Noticing Koha::MessageAttribute(s) classes were already introduced while this Bug was in pending status. Need to adjust current patches - remove Koha::Patron::Message::Attribute(s) and rename transport classes to match naming convention of Koha::MessageAttribute(s). Commenting to Bugzilla. 0.50 Actions
05.07.2022 14:57 15.06.2022 Lari Taskula Design Feature #944: Avoid changing tabs on page reload on holds awaiting pickup page Designing feature. Looking at example from Koha's reports page, it uses cookies to store current tab. 1.00 Actions
05.07.2022 14:57 05.07.2022 Lari Taskula Development Feature #944: Avoid changing tabs on page reload on holds awaiting pickup page Implementing feature and testing. 2.00 Actions
18.10.2022 21:18 13.10.2022 Lari Taskula Design Feature #943: Notify librarian of an available item in pickup library when checked out to a different library Designing feature. Notifying librarian is quite easy to do. Sketching on what it could look like. A flowchart sent by the client is asking to iterate holds and checking available item at pickup library until no such item is found. It may be out of scope but looking into it anyway. Looks like heavy hold queue logic refactoring would be needed. Reporting findings to the client. 8.00 Actions
06.09.2022 21:13 07.09.2022 Lari Taskula Development Feature #942: Change item level hold to biblio level hold Starting to design this feature. Playing with GUI implementation and thinking of how to implement business logic. It is documented that a record cannot have mixed biblio/item level holds - all holds following the first one must be of same type. This places a big restriction on how this feature can be done. Asking client for their ideas. 1.00 Actions
(26-50/182) Per page: 25, 50, 100, 500

Also available in: Atom CSV