[Koha-bugs] [Bug 35648] New: Allow sorting of patron categories in Overdue notice/status triggers
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35648 Bug ID: 35648 Summary: Allow sorting of patron categories in Overdue notice/status triggers Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs@lists.koha-community.org Reporter: jheltibri...@rcplib.org QA Contact: testo...@bugs.koha-community.org It would be really helpful to be able to choose the sorting method on the Overdue notice/status triggers page. Currently, the patron categories are sorted by Code. We include the branch name at the start of the Category name. If we could sort by that instead of the Code, we could find our branch's patron categories much quicker in order to make changes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 34315] Provide an alternative to the mailing lists - Discourse
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34315 --- Comment #10 from Thomas Dukleth --- [Correcting myself.] There is a Discourse option for setting the minimum trust level of users for creating a topic by email. Unfortunately, the option is ambiguously named and easy to mistake for a more general function of having Discourse receive email. Yet, the option exists and is easy to reduce from default trust level 2 to trust level 0 matching replying by email to an existing topic and allowing people who work more efficiently using email to do so without unnecessary extended use of inefficient forum software. [There is much hardcoded behaviour from the developers at Civilized Discourse Construction Set, the company which controls Discourse, who often do not understand why anyone would prefer otherwise but creating new topics by email does have an option for setting the minimum trust level instead of the default trust level 2 value. Lack of formal documentation beyond the most basic level for installation is problematic. Most of what passes for documentation is either the code [upon which I have needed to rely too much]; the user interface; or very brief explanations of some narrow subtopic often in answer to a specific question buried in https://meta.discourse.org .] The ambiguously named options for email_in* are distinct from reply_by_email* despite "reply by email" needing to be received as "email in" the Discourse instance in order to function. Perhaps the ambiguity in naming is an artefact of historical development order. Replying by email depends upon a token which incorporates both the topic and the user sending the reply. Creating a new topic by sending an email message depends on the special email address for the category in which the topic [email subject] would go. Categories might be very broad such as devel, translate, etc. and use tags for faceted discovery. There is no provision for assigning tags to a topic in Discourse from sending an email message but tags beyond list name are generally not a feature of exchanging mailing list email even if that could be useful. [Using the forum software for tag assignment also helps avoid proliferation of tag names from misspellings and unnecessary different names if users avoid such with autocompletion in tag assignment.] email_in: (Allow users to post new topics via email. After enabling this setting, you will be able to configure incoming email addresses for groups and categories.) email_in_min_trust: (The minimum trust level a user needs to have to be allowed to post new topics via email.) reply_by_email_enabled: (Enable replying to topics via email) To my knowledge, there is no reply_by_email_min_trust option. Replying to an existing topic is considered to have less need for trust in Discourse which is either enabled for all users of for none and seems to be hard coded at trust level 0 if enabled which is fine. The trust level for posting a new topic is considered more concerning for spam abuse. There are better ways of controlling spam than restricting users from doing most of what people need to do for communicating regularly on mailing lists. The developers at Civilized Discourse Construction Kit, approach spam control by having very little restriction for spammers to create an account but excessive restrictions for anyone to contribute usefully. Reducing the likelihood that spammers would have be approved to obtain an account is better than deleting spam which could have been avoided. Spam in topic creation is likely to be much more obvious and thus stopped quickly and especially when created for email can be reduced by email spam checks more easily than topic reply spam because the email subject header is used for topic creation. Spam control for email before it would even be available to Discourse can make email submission the least likely to be the source to Discourse post spam but enabling email spam control requires configuration for incoming mail the opposite of recommendation in Discourse. There are other defaults which need to be changed for email compatibility in Discourse to be meaningful without being forced to use the forum software for an extended period. Here, I have merely corrected my error about the presence of an option and identified the difficulty of default choices to which many Discourse users have objected. There are also problematic hard coded issues which we do not have for email_in_min_trust. (In reply to Thomas Dukleth from comment #9) [...] > Living up to the promise of email > compatibility will require either modifying a hard coded design, creating > some plugin to do so, or constantly running a script to elevate everyone to > trust level 2 merely to allow known users to use email for posting with > their own topic as opposed to merely answering about topics raised by others > without being forced to use the forum software for an extended period. -- You are receiving
[Koha-bugs] [Bug 35475] Untranslatable strings in booking modal and JS
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35475 --- Comment #5 from Katrin Fischer --- Created attachment 160285 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160285=edit Bug 35475: Improve concatenated string and fix error in JS file Fixes 2 problems noted in comment#2 and comment#3 on the bug report. -- 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 35475] Untranslatable strings in booking modal and JS
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35475 Katrin Fischer changed: What|Removed |Added Attachment #159704|0 |1 is obsolete|| --- Comment #4 from Katrin Fischer --- Created attachment 160284 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160284=edit Bug 35475: Makes strings in booking JS file translatable This makes several strings in the booking specific JS file translatable. To test: * Make an item bookable: * Find a record with items in your catalog or create one * From the details page, switch to the items tab * Mark items as bookable * Add a booking, verify the modal works as expected * Check the bookings tab * Verify the column headings of the bookings table show correctly * Verify the "Biblio level" and "Item" in the calendar show Note: Months don't translate, this will be a separate bug * Cancel a booking, edit a booking... make sure everything works as expected * If you can: Install a translation and verify strings show up in po files as expected -- 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 35475] Untranslatable strings in booking modal and JS
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35475 Katrin Fischer changed: What|Removed |Added Status|Failed QA |Signed Off -- 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 35631] Default Z39.50 target syntax to match sys pref marcflavour
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35631 Katrin Fischer changed: What|Removed |Added Version|23.05 |master --- Comment #2 from Katrin Fischer --- Pre-selecting the marcflavour format makes a lot of sense, also shortening the list if it has on consequence. How should we migrate existing entries? -- 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/
[Koha-bugs] [Bug 35634] Permissions mismatch for vendor issues
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35634 Katrin Fischer changed: What|Removed |Added Keywords||RM_priority -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 35625] Add support for system flag to additional fields
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35625 --- Comment #7 from Katrin Fischer --- Do you have a use case/example maybe? I am a little hesitant because the linked fields are harder to query for libraries and we need to join another table (performance?). Would we need guidelines/agreement about when to use additional fields and when to extend the original tables? -- 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 35486] When editing an authority show all subfields of the heading field
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35486 Katrin Fischer 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 34423] (proof-of-concept) Bugzilla could look better with a new skin
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34423 --- Comment #1 from Katrin Fischer --- Hi Jake, I missed to tell you earlier: but I quite like it. I especially like the switch in fonts to non-serif for the labels etc. Is this something we could put on the roadmap? https://wiki.koha-community.org/wiki/Road_map_24.05 -- 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/
[Koha-bugs] [Bug 28869] If authorized values for STACK (shelving control number) are > 127 things explode
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28869 --- Comment #7 from Katrin Fischer --- (In reply to Marcel de Rooy from comment #5) > Just some related questions here. > > Should we save authorised_values.id in connected fields? Perhaps > theoretically, but it does not sound very practical at this point in our > codebase. So NO. Agreed. > Should we adjust other item fields that are of integer type connected to AV > where the same problem actually may occur? Move them all to varchar(80)? It > feels a bit like overkill? > These are: > | stack | tinyint(1) | # on this report > | notforloan| tinyint(1) | > | damaged | tinyint(1) | > | itemlost | tinyint(1) | > | withdrawn | tinyint(1) | > | restricted| tinyint(1) | > > IF doing so, we could look at default values. They are not completely > consistent, since damaged and withdrawn default to 0. > `restricted` tinyint(1) DEFAULT NULL COMMENT 'authorized value defining use > restrictions for this item (MARC21 952$5)', > `stack` tinyint(1) DEFAULT NULL, > `ccode` varchar(80) DEFAULT NULL COMMENT 'authorized value for the > collection code associated with this item (MARC21 952$8)', > `location` varchar(80) DEFAULT NULL COMMENT 'authorized value for the > shelving location for this item (MARC21 952$c)', Standardizing the default values would be nice, but I am very hesitant about changing the datatype on the listed fields to varchar. My doubts are about the handling in our code and in reports. I know that we make numerical comparisons on these fields, like notforloan negative and positive values are treated differently within the codebase. Restricted = 1 has a special meaning. I would leave the status as is and only change stack, as it doesn't seem to belong in the list (not a status). > I thought about warning for a wrong value in an item field of type > integer/date BEFORE saving. Now we can just enter something in various > fields, save, get no warning and come back later to discover that our data > is lost. E.g. the example of 127 for a higher number. (Coming back as 127 > with a warning in the editor.) Or just 0 for a string. I have helped a lot of people "fix" this problem over time, so better handling in the GUI would be desirable. Maybe instead of fixing the item editor etc. we should fix the authorised values editor instead. > But since this originates from AV. We should perhaps add a restriction > THERE! Why not add an AV column that allows you to only enter tinyints > instead of 80 char codes? If we solve it in AV, there will be no problem in > items? Agreed :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 28844] Suggestion from existing title can alert patron in error
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28844 Katrin Fischer changed: What|Removed |Added Keywords||RM_priority -- 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 28844] Suggestion from existing title can alert patron in error
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28844 --- Comment #48 from Katrin Fischer --- Maybe we could extend the relationship later. At the moment we create an order from a suggestion, so a 1:1 makes sense. When I tested this my main concern was to ensure that the suggestions existing previously to this fix would still work, patrons receiving emails etc. Did you take a look at that aspect? -- 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 27113] Elasticsearch: Autocomplete in search
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 --- Comment #124 from Katrin Fischer --- I believe we had a plan here involving solving bug 25870 first as a better base for the work here. It's already linked as a dependency, but needs some more work right now. I know a lot of people would love to see this functionality and I hope we can figure out the implementation bits this cycle. -- 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 26297] Rest API: add a route to list patron categories
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26297 --- Comment #16 from Katrin Fischer --- Hi Pedro, as we have such a super specific column name here... we could just update the reports using the column maybe? I am not opposed to fixing the database in this case, just wonder if want to maybe do it separately from this bug? -- 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 20307] Language overlay for authorized values
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20307 --- Comment #109 from Katrin Fischer --- (In reply to Jonathan Druart from comment #108) > Give your opinion on the 2 implementations, that's the only way to make > things move forward. Is this something we could maybe gain more attention for by putting it on the roadmap or on the agenda for a meeting? I really want it to happen, but not sure if I could give helpful feedback on implementation. -- 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 26567] Allow to limit subscription search to subscriptions with routing lists
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26567 Katrin Fischer changed: What|Removed |Added Status|Needs Signoff |Failed QA --- Comment #5 from Katrin Fischer --- Hi Esther, thanks for testing! The subscription should only appear once in the list as we only want to check for "has a routing list". We'll also be needing unit tests for the change in SearchSubscriptions. I am also pondering if we should rename the search option... Maybe: "Has routing list"? This could make it clearer that we are not looking for routing lists, but for subscriptions still. -- 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 32610] Add ability to specify patron attribute as a date
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32610 --- Comment #35 from Katrin Fischer --- (In reply to Pedro Amorim from comment #34) > Not a blocker, but why the design decision of restricting a date attribute > type to not be able to also be repeatable? > > I can't find many good examples of how a repeatable date field would be > useful, but I don't understand why we wouldn't allow it either. Mostly because I wanted to keep it a bit more simple and thought that could still be done later if required. I had picked this up to work on in my free time, because it seemed something that people were interested in, but it grew quickly and got more complicated than I had first imagined. I think I'd definitely need some help to solve the import issue (good testing btw!) and probably the tests as well. I am also a bit worried about the batch patron edit - at the time of me writing this patch set I had some trouble testing it because of a blocking bug. -- 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 35644] Remove/edit Last Seen date on an item when it was incorrectly marked as seen
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35644 Katrin Fischer changed: What|Removed |Added Resolution|--- |WORKSFORME Version|22.11 |master Status|NEW |RESOLVED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 35644] Remove/edit Last Seen date on an item when it was incorrectly marked as seen
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35644 --- Comment #2 from Katrin Fischer --- Something like 952$L or so would work. -- 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/
[Koha-bugs] [Bug 35644] Remove/edit Last Seen date on an item when it was incorrectly marked as seen
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35644 --- Comment #1 from Katrin Fischer --- Hi Angela, you can crate a capital letter subfield in your MARC frameworks and map the datelastesen column to it. That will make it visible and you will be able to edit it in the item form. -- 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/
[Koha-bugs] [Bug 35575] Acquisition framework fails to display required next 942 $c when defined as mandatory
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35575 --- Comment #5 from Katrin Fischer --- (In reply to Angela Berrett from comment #4) > We would like to see the ability to configure this hardcoded form as well. > Mainly, the ability to apply the item templates to this form so it can > autofill certain fields when the item is created from here. This may be a > completely different issue, but we have talked about other changes we would > appreciate the ability to make. Hi Angela, if you set your defaults for 952 in the ACQ framework this should already work. The item form is completely configurable, only the part for the bibliographic data is hardcoded if not using UseACQFrameworkForBiblioRecords. -- 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/
[Koha-bugs] [Bug 35628] Add additional statuses to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 Martin Renvoize changed: What|Removed |Added CC||katrin.fisc...@bsz-bw.de -- 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 35628] Add additional statuses to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 --- Comment #14 from Martin Renvoize --- Note to self, add a class for status-* for each status to table rows in display so people can custom style different state tickets should they wish to. -- 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 32435] Add resolution types to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32435 Martin Renvoize changed: What|Removed |Added Status|ASSIGNED|Needs Signoff -- 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 35628] Add additional statuses to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 Martin Renvoize changed: What|Removed |Added Assignee|koha-b...@lists.koha-commun |martin.renvoize@ptfs-europe |ity.org |.com -- 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/
[Koha-bugs] [Bug 35628] Add additional statuses to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 Martin Renvoize changed: What|Removed |Added Attachment #160273|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 35628] Add additional statuses to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 --- Comment #13 from Martin Renvoize --- Tha is for testing Esther, it looks like you just beat my final ammended patch here . I'm offline for Xmas now, but it look like if I obsolete your signed off patch you should be able to test again with the correct one applied. That final patch does two things, it fixes the overflow your spotted and also switches the display to use the description field of the authorized value instead of the coded one. Many thanks again for testing, it really motivated me to keep working on this series. -- 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/
[Koha-bugs] [Bug 33431] Make code use C4::Context->yaml_preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33431 --- Comment #12 from David Nind --- Testing notes (using KTD) - for patch 3 (see comment #8): 1. Add LC: 010$a to RisExportAdditionalFields and export a record as RIS. It should still work as usual and be the same before and after the patch. I used record 262 (Perl programming). 2. Have something set on `MarcFieldsToOrder` and add an order using an ISO2709 (mrc) file. Should work as usual. 2.1 I used the steps from comment 22 and sample files for bug 34645 3. Have something set for `UpdateItemWhenLostFromHoldList` and a couple pending holds. See this ByWater Solutions tutorial "Alert Patrons When Hold is Cancelled" https://bywatersolutions.com/education/monday-minutes-alert-patrons-when-hold-is-cancelled -- 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 33431] Make code use C4::Context->yaml_preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33431 David Nind changed: What|Removed |Added Attachment #160247|0 |1 is obsolete|| --- Comment #11 from David Nind --- Created attachment 160283 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160283=edit Bug 33431: Fix remaining cases This patch tweaks three remaining cases, that are not covered by tests. To test: 1. Apply this patch 2. Make use of those places => SUCCESS: No behavior change Signed-off-by: David Nind -- 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 33431] Make code use C4::Context->yaml_preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33431 David Nind changed: What|Removed |Added Attachment #160246|0 |1 is obsolete|| --- Comment #10 from David Nind --- Created attachment 160282 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160282=edit Bug 33431: Make C4::Record use C4::Context->yaml_preference This patch makes what the title says. To test: 1. Run: $ ktd --shell k$ prove t/db_dependent/Rec* => SUCCESS: Tests pass 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests pass! 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi Signed-off-by: David Nind -- 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 33431] Make code use C4::Context->yaml_preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33431 David Nind changed: What|Removed |Added Attachment #160245|0 |1 is obsolete|| --- Comment #9 from David Nind --- Created attachment 160281 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=160281=edit Bug 33431: Make C4::Circulation use C4::Context->yaml_preference This patch removes manual YAML handling for sysprefs in C4::Circulation. It also makes C4::Context->yaml_preference not warn when undef is retrieved from the sysprefs. To test: 1. Run: $ ktd --shell k$ prove t/db_dependent/Circulation* => SUCCESS: Tests pass! 2. Apply this patch 3. Repeat 1 => SUCCESS: Tests pass! 4. Sign off :-D Signed-off-by: David Nind -- 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 33431] Make code use C4::Context->yaml_preference
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33431 David Nind changed: What|Removed |Added Status|Needs Signoff |Signed Off -- 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 34324] Merge OPACProblemReport and CatalogConcern functions
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34324 Martin Renvoize changed: What|Removed |Added Depends on||35628 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add additional statuses to catalog concerns -- 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 35628] Add additional statuses to catalog concerns
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 Martin Renvoize changed: What|Removed |Added Blocks||34324 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34324 [Bug 34324] Merge OPACProblemReport and CatalogConcern functions -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ 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 33532] Catalog concerns - Title of the page says Tools instead of Cataloging
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33532 Martin Renvoize changed: What|Removed |Added CC||martin.renvoize@ptfs-europe ||.com Status|Pushed to master|RESOLVED Resolution|--- |FIXED -- 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/
