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

[Bug 25767] New: Add Koha::Item::Transfer->receipt method
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25767 Bug ID: 25767 Summary: Add Koha::Item::Transfer->receipt method Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We should have a `receipt` method on the Koha::Item::Transfer object to allow marking the item as received and the transfer as complete. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 --- Comment #16 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- I gave sign-off credit to the wrong librarian! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187119|0 |1 is obsolete| | --- Comment #15 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Created attachment 187134 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187134&action=e… Bug 15248: Use record matching rules to find duplicate while cataloging This patch allows to configure how Koha searches for duplicates when cataloging manually by using a record matching rule. For each framework we can now set a record matching rule to use when searching for duplicates. This allow to use different matching rules while in acquisition for instance (ACQ framework). If a matching rule is selected, we also have the ability to forbid the creation of duplicate: if a duplicate is found and this option is enabled, the usual option to create a duplicate will be hidden. If no matching rule is selected, then the default matching mechanism is used. Test plan: 1. Create a record matching rule matching on ISBN Threshold: 100 Record type: biblio Match point: Search index: "isbn" Score: 100 Tag: "020" (or "010" for UNIMARC) Subfields: "a" Offset: 0 Length: 0 Normalization rule: Remove spaces No match checks 2. Edit the default MARC framework and select the new matching rule and enable "Forbid duplicate creation" 3. Create a biblio with an ISBN 4. Make sure your new biblio is indexed in Zebra or ES 5. Try to create a biblio with the same ISBN. You should see a warning about the duplicate with no option to create the duplicate biblio 6. In the acquisitions module, in a basket add a new order from an external source (requires a configured Z39.50/SRU server) 7. Choose a record with an ISBN 8. Once the order is created, try to create a new order from an external source and choose the same record. You should see a warning about the duplicate. 9. Edit the record matching rule and disable "Forbid duplicate creation" 10. Redo step 5. Now there should be an option to create the duplicate record. 11. Redo step 8. Now there should be an option to create the duplicate record. 12. Run the following test scripts: - t/db_dependent/Search.t - t/db_dependent/Matcher.t Sponsored-by: SCD Lyon2 Signed-off-by: Andrew Fuerste Henry <andrew(a)bywatersolutions.com> Signed-off-by: Jeanne Maurielle <jeanne.mauriello(a)mainlib.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

انضم لحساب Canva Pro مجانًا الآن
by Jessica Wuttig 30 Sep '25

30 Sep '25

انضم الآن إلى حساب Canva Pro مجانًا عبر رابط الدعوة المخصص للمعلمين والطلاب في 2025، واستفد من جميع المزايا المدفوعة دون أي تكلفة. في هذا المقال نوضح لك كيفية الحصول على دعوة مجانية لحساب Canva Pro Edu، وما الذي يميزه عن الحسابات الأخرى، والخطوات العملية للتسجيل. https://www.targir.com/2025/02/canva-pro.html ما هو Canva Pro؟ Canva منصة تصميم مشهورة عالميًا تتيح إنشاء عروض تقديمية، ملصقات، منشورات اجتماعية، فيديوهات وغير ذلك بسهولة. الحساب المجاني يوفر أدوات وقوالب محدودة، بينما يقدم Canva Pro مكتبة ضخمة من الصور والفيديوهات، أدوات احترافية مثل إزالة الخلفية، وتخزين سحابي بسعة كبيرة. أنواع الحسابات الحساب المجاني: يتيح الوصول لآلاف القوالب وصور ورسومات محدودة، مع 5 جيجا تخزين. مناسب للمبتدئين. Canva Pro: مدفوع يوفر أكثر من 100 مليون صورة، قوالب متميزة، 1 تيرابايت تخزين، وأدوات مثل تغيير مقاسات التصميم. Canva Teams: مصمم للمؤسسات، مع مزايا تعاون فوري وتخصيص العلامة التجارية. Canva Pro Edu: مجاني للمعلمين والطلاب، يحتوي على جميع ميزات Canva Pro بالإضافة إلى أدوات تعليمية. كيف تحصل على Canva Pro Edu مجانًا؟ – التسجيل عبر رابط دعوة رسمي خاص بالتعليم. – إنشاء حساب جديد أو استخدام بريدك التعليمي إن توفر. – بعد قبول الدعوة، يتحول حسابك تلقائيًا إلى Canva Pro Edu مجاني بكامل المزايا. ماذا تحتاج للتسجيل؟ – أن تكون معلمًا أو طالبًا بمؤسسة تعليمية. – بريد إلكتروني مرتبط بالتعليم (مثل edu). – الانضمام عبر رابط دعوة نشط. هل يمكن الحصول على Canva Pro بطرق أخرى؟ نعم، هناك نسخة تجريبية مجانية لمدة 30 يومًا متاحة للجميع عبر الموقع الرسمي. خلال هذه الفترة تستمتع بجميع المزايا، ويمكنك إلغاء الاشتراك قبل انتهائها لتجنب الرسوم. أما الحصول على Canva Pro شخصي دائمًا بشكل مجاني فغير ممكن إلا عبر الدعوة التعليمية. أهم المزايا التي يقدمها Canva Pro Edu مجانًا – مكتبة تضم أكثر من 100 مليون صورة ورسوم وفيديوهات. – أكثر من 600 ألف قالب احترافي. – أدوات متقدمة مثل إزالة الخلفية وتغيير مقاسات التصاميم. – تخزين سحابي 1 تيرابايت. – إمكانية العمل الجماعي مع الطلاب والزملاء على مشاريع مشتركة. لماذا تختار Canva Pro Edu؟ هذا الحساب يمنحك جميع أدوات Canva Pro دون تكلفة، وهو مثالي للمدرسين لإعداد دروس تفاعلية، وللطلاب لإنشاء مشاريع وعروض احترافية. يساعدك على رفع جودة أعمالك ويوفر موارد ضخمة جاهزة للاستخدام. خاتمة إذا كنت طالبًا أو معلمًا، فإن أفضل طريقة للحصول على Canva Pro مجانًا هي عبر رابط الدعوة إلى Canva Pro Edu. بهذه الخطوة ستفتح لك جميع الأدوات المميزة دون أي رسوم. سجّل الآن واستفد من فرصة مذهلة تتيح لك تطوير تصاميمك التعليمية والشخصية، والوصول إلى مستوى احترافي باستخدام Canva Pro Edu في 2025.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia(a)bugs.koha-communit |andrew(a)bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15248] Make it possible to configure duplicate check on bibliographic records
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15248 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #187105|0 |1 is obsolete| | --- Comment #14 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Created attachment 187119 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187119&action=e… Bug 15248: Use record matching rules to find duplicate while cataloging This patch allows to configure how Koha searches for duplicates when cataloging manually by using a record matching rule. For each framework we can now set a record matching rule to use when searching for duplicates. This allow to use different matching rules while in acquisition for instance (ACQ framework). If a matching rule is selected, we also have the ability to forbid the creation of duplicate: if a duplicate is found and this option is enabled, the usual option to create a duplicate will be hidden. If no matching rule is selected, then the default matching mechanism is used. Test plan: 1. Create a record matching rule matching on ISBN Threshold: 100 Record type: biblio Match point: Search index: "isbn" Score: 100 Tag: "020" (or "010" for UNIMARC) Subfields: "a" Offset: 0 Length: 0 Normalization rule: Remove spaces No match checks 2. Edit the default MARC framework and select the new matching rule and enable "Forbid duplicate creation" 3. Create a biblio with an ISBN 4. Make sure your new biblio is indexed in Zebra or ES 5. Try to create a biblio with the same ISBN. You should see a warning about the duplicate with no option to create the duplicate biblio 6. In the acquisitions module, in a basket add a new order from an external source (requires a configured Z39.50/SRU server) 7. Choose a record with an ISBN 8. Once the order is created, try to create a new order from an external source and choose the same record. You should see a warning about the duplicate. 9. Edit the record matching rule and disable "Forbid duplicate creation" 10. Redo step 5. Now there should be an option to create the duplicate record. 11. Redo step 8. Now there should be an option to create the duplicate record. 12. Run the following test scripts: - t/db_dependent/Search.t - t/db_dependent/Matcher.t Sponsored-by: SCD Lyon2 Signed-off-by: Andrew Fuerste Henry <andrew(a)bywatersolutions.com> Signed-off-by: Phillip Berg <phillip.berg(a)mainlib.org> -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 40914] New: 653 subject genre should display as a genre
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40914 Bug ID: 40914 Summary: 653 subject genre should display as a genre Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 187118 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=187118&action=e… GENRE is not with the genres in the bibliographic detail view The second indicator of the 653 defines the index term category. For example, if the second indicator is a 6, the index term is assigned as a genre. However, Koha seems to consider the 653 as a general subject and ignores the second indicator. In the genre example, the index term should appear with the genres in the bibliographic detail view of the record, but it is not. To Replicate 1. Edit a record and add a 653_6 $a GENRE. Save 2. View the record and see the genre is included with the Subjects and not the Genres. (see attached image) Link the Library of Congress page for the 653. https://www.loc.gov/marc/bibliographic/bd653.html Consideration may be needed for the other categories. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 27637] New: Allow ReservesMaxPickUpDelay to be adjusted based on item values
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27637 Bug ID: 27637 Summary: Allow ReservesMaxPickUpDelay to be adjusted based on item values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The syspref ReservesMaxPickUpDelay contains a number of days to be added to the current date in order to derive the expiration date for a hold. It allows no variation for item types, libraries, etc. I propose a new companion syspref of ReservesMaxPickUpDelayAdjustments (or something). It'd take a set of item table fields, values, and numbers to be added to the ReservesMaxPickUpDelay value. So something like: holdingbranch: CPL: 2 itype: DVD: -3 Would mean holds on items at CPL would get 2 extra days, holds on DVDs would get 3 fewer days. Whatever syntax we arrive at should allow grouping conditions, so a library could adjust pickup delays for only a specific itype at a specific branch, for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 40912] New: Receive shipments button requires full acquisitions permissions not just order_receive
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '25

30 Sep '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40912 Bug ID: 40912 Summary: Receive shipments button requires full acquisitions permissions not just order_receive Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: blawlor(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org The permission check to display the Receive shipments button in the Vendors table and Vendors page requires full acquisitions permissions. (Any route like koha/acquisition/vendors) It doesn't just check just for the sub permission order_receive. >From VendorShow.vue line 48: <ToolbarButton v-if=" vendor.active && vendor.baskets_count > 0 && isUserPermitted('CAN_user_acquisition_order_receive') " :to="{ path: '/cgi-bin/koha/acqui/parcels.pl', query: { booksellerid: vendor.id }, }" icon="inbox" :title="$__('Receive shipments')" callback="redirect" /> This looks like it should work to check for the order_receive sub permission, but it only renders when the user has full acquisitions permissions. This is similar to bug 40684, so my guess is it needs a similar fix in /api/v1/swagger/paths/acquisitions_orders.yaml -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2