Project

General

Profile

Spent time

Filters

Apply Clear

Hours: 344.53

Created Date User Activity Issue Comment Hours
08.01.2024 13:08 08.01.2024 Lari Taskula Maintenance Support #1138: Tietuenäytön muokkaus ei toimi päivityksen jälkeen Tutkittu ongelmaa ja löydetty Bug 35383 0.50 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
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
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
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
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
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
10.11.2022 02:28 10.11.2022 Lari Taskula Development Feature #942: Change item level hold to biblio level hold Rebasing new conflicts 0.50 Actions
04.11.2022 00:04 04.11.2022 Lari Taskula Communication Feature #942: Change item level hold to biblio level hold Testing and commenting to Bugzilla. 0.25 Actions
03.11.2022 20:53 03.11.2022 Lari Taskula Development Feature #942: Change item level hold to biblio level hold QA failed because patch didn't handle reserves.item_level_hold column. Implementing a fix and unit tests for it, attaching patch to Bugzilla. 0.75 Actions
26.10.2022 13:47 26.10.2022 Lari Taskula Communication Feature #942: Change item level hold to biblio level hold Commenting on Bugzilla 0.25 Actions
24.10.2022 23:50 25.10.2022 Lari Taskula Maintenance Feature #942: Change item level hold to biblio level hold Squashing patches, responding to a comment in Bugzilla, updating test plan. 0.50 Actions
18.10.2022 23:03 19.10.2022 Lari Taskula Development Feature #942: Change item level hold to biblio level hold Implementing a select dropdown as suggested by a patch tester. Also found a bug in old patches so fixing those. 0.75 Actions
18.10.2022 22:18 19.10.2022 Lari Taskula Development Feature #942: Change item level hold to biblio level hold Reading feedback in Bugzilla, rebasing patches and adding a tooltip. Realizing tooltip/aria-label is wrong when first clicked. Rewording it to "toggle hold type". Changing icon to fa-chain(-broken). Attaching more patches. 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.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
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
05.10.2022 16:40 05.10.2022 Lari Taskula Development Feature #942: Change item level hold to biblio level hold Implementing feature. First, approaching functionality from old school CGI scripts but then came into the conclusion that the logic for this feature must be placed into a Koha-object so that it can easily be covered by unit tests. Creating Koha::Hold::change_type and unit tests for the function. Moving on to GUI, stole the red X design from neighbouring columns of existing holds, it looks pretty nice. A hidden input field is placed under the red X, dictating if hold type should be changed in modrequest.pl or not. In order to change that input, some JavaScript was required. Adding a jQuery event listener to holds.js to manipulate input values based on clicks on the red X. Creating a new Bugzilla Bug 31692, documenting issue, writing test plans for the patches and pushing patches to Bugzilla. 8.00 Actions
05.10.2022 16:36 05.10.2022 Lari Taskula Design Feature #942: Change item level hold to biblio level hold Design, trying a couple of different solutions in GUI. 3.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
05.10.2022 16:50 07.07.2022 Lari Taskula Communication Feature #940: Remove hold to a biblio if a non-holdable itemtype from the same biblio is checked out Emailing with client, July/August 1.00 Actions
06.07.2022 23:30 07.07.2022 Lari Taskula Communication Feature #941: Bug 22456 - Allow patrons to cancel their waiting holds Commenting on Bugzilla about a possible scenario where patron wants to revert the cancellation request, had to inspect patches for reference. 1.00 Actions
05.07.2022 18:07 05.07.2022 Lari Taskula Learning Feature #940: Remove hold to a biblio if a non-holdable itemtype from the same biblio is checked out Going through Finnish Koha libraries' documentation and finding a possible resolution to this issue that requires a change in circulation rules workflow. Instead of defining hold restriction at "Default holds policy by item type", where exissting holds will not cancel when non-holdable itemtype is checked out, to placing the hold restrction at normal circulation rules table, where the holds do cancel when checking out a non-holdable itemtype. 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
(1-25/182) Per page: 25, 50, 100, 500

Also available in: Atom CSV