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

[Bug 11472] New: MARC21 008 plugin should consult leader to set default type of material
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '14

06 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11472 Bug ID: 11472 Summary: MARC21 008 plugin should consult leader to set default type of material Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, when you use the MARC21 008 plugin to edit field positions, the type of material is always set to BKS, regardless of the actual material type of the record. This means that you always have to change the material type in the fixed field editor to the appropriate value. It would be nice if the type of material were determined by the current leader value. The "material type" in this context is determined by the Leader/06 and Leader/07. The "input conventions" heading near the bottom of http://www.loc.gov/marc/bibliographic/bdleader.html contains a "dependencies" section that designates the appropriate material type for the 008 based on the Leader/06-07. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 10438] New: Packages naming/versioning broken
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10438 Bug ID: 10438 Summary: Packages naming/versioning broken Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com CC: robin(a)catalyst.net.nz Our current packages naming and versioning doesn't support what we claim: if someone wants to maintain an specific version then we'll let him. It is also unnecesarilly complex for the users too. The current schema provides only two stable versions support at a given time, with 'oldstable' and 'stable' dists as a way of specifying that. Not only has that versions limitation (which could be fixed adding something like 'olderoldstable') but is also difficult for the user who has to check whether to change stable to oldstable to avoid unwanted version jump. This makes maintenance difficult even for IT stuff (is not *that* difficult, but is unnecesary). I propose changing the packages naming schema to something like: - Dists: stable (for the stable releases), devel (for the development branches) - Packages naming/version: pick the one VirtualBox uses and have: koha-common-3.8 koha-common-3.10 koha-common-3.12 and so on as packages names. Versioned with their corresponding full version (with minor release number) as it obvoiusly should. I think changing ths should be a minor task, and would make install instructions easier to write, maintain and follow, and would allow us to support more than two stable releases at a time. In a simpler way. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8956] New: Split serials enumeration data into separate fields
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8956 Priority: P5 - low Change sponsored?: --- Bug ID: 8956 CC: colin.campbell(a)ptfs-europe.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Split serials enumeration data into separate fields Severity: enhancement Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Serials Product: Koha Work to be done 1) Add an option 'published_end_date' to the serials table. It will only be used to represent the last issue date in a bound volume. 2) Data clean up: Extract the published dates from the existing enumeration field. Populate serials.publisheddate and serials.published_end_date with this data. 3) Strip the publishing dates from their enumeration fields (probably by simply deleting matched parentheses and everything in between them). 4) In order to break the “Numbered” field into three columns, add X, Y and Z columns to serials, as well as X, Y and Z descriptions columns to the subscription table. 5) Port existing data into these columns. Once all the enumeration fields are of the correct format, e.g., Vol. X No. Y, we can use everything preceding {X} as X_Description, and everything preceding {Y} until } as Y_Description. Another way to look at this is if we split on {?}, we will have all the label fields in order of use. Once we have the label fields, we can parse those out of the enumeration string, and we will have the set of values they represent. 6) Add a calendar widget for published on and expected on (serials-edit.pl). This will require librarians to enter new dates in the accepted format. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 67

[Bug 9851] New: way to get full records for purchase suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9851 Bug ID: 9851 Summary: way to get full records for purchase suggestions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com It would be nice if there were a way to get full records for purchase suggestions - a replace via Z39.50 option maybe. Right now most libraries order from a batch given to them from a vendor or from a Z target to get full records, but if they do this then their orders aren't linked to the suggestions. The only way to keep the suggestion linked is to order from it and in essence a brief record. I don't have a good suggestion here, but thought I should share the idea in case someone else has a solution. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 6070] New: On a new order defined from suggestion some fields were missing.
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '14

05 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6070 Bug #: 6070 Summary: On a new order defined from suggestion some fields were missing. Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org (MT #4937) The missing fields : publicationyear, place, collectiontitle. More the layout has been modified. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 54

[Bug 10665] New: koha-index-daemon-ctl.sh needs mysql dependency
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '14

04 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10665 Bug ID: 10665 Summary: koha-index-daemon-ctl.sh needs mysql dependency Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org koha-index-daemon-ctl.sh is a init script for koha-index-daemon from Koha::Contrib::Tamil::IndexerDaemon. When starting system, this script needs to be started after the MySQL server because it uses it to access to Koha database. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 11649] New: Always use words "copy number"
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '14

04 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11649 Bug ID: 11649 Summary: Always use words "copy number" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In most cases, the value of items.copynumber is displayed using the words "Copy number". But in some cases, it is just "Copy". It would be better to always use "Copy number" because in translation the word "Copy" means the action of coping. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 11648] New: Use word item instead of copy
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '14

04 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11648 Bug ID: 11648 Summary: Use word item instead of copy Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolyn.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Sometimes, the word copy/copies is use to speak about item/items. It would be better to use only item because translation of the word copy depends on context, it should be used only when speaking about copy like in "copy and paste". -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 11550] New: GetOrder returns something even if the order does not exist
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '14

04 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11550 Bug ID: 11550 Summary: GetOrder returns something even if the order does not exist Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org I did not find somewhere it can cause a problem, but the GetOrder routine always returns a hashref with a key 'orderdate'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 11465] New: Show counts and amounts on OPAC your summary tabs
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '14

04 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11465 Bug ID: 11465 Summary: Show counts and amounts on OPAC your summary tabs Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, when you enter your patron account on the OPAC, you see the "Checked out" tab on the "your summary" page. Currently, to see the number of holds, number of waiting items, number of check outs, and the amount of fines, you have to click on the tabs. However, one of our librarians has pointed out that it might be better to see the numbers at a glance (especially in regards to fines), as patrons might not realize that they need to click through to view counts and amounts. I propose adding the counts and amounts to the tab headings themselves. This way, patrons will know at a glance where they stand. They can then click the tabs for more details. The counts/amounts are already being passed to the template, so it's an easy change. -- My main question is...do I do patches for bootstrap, ccsr, and prog? -- You are receiving this mail because: You are watching all bug changes.

1 11