This project is mirrored from git://git.koha-community.org/koha.git. Updated .
  1. 13 Feb, 2018 1 commit
  2. 15 Jan, 2018 1 commit
    • Mark Tompsett's avatar
      Bug 19937: Silence warnings t/db_dependent/www/batch.t · 35249256
      Mark Tompsett authored
      TEST PLAN
      ---------
      1) Run the following on a kohadevbox:
          git checkout -b bug_19937 origin/master
          sudo koha-shell -c bash kohadev
          prove t/db_dependent/www/batch.t
          cat /var/log/koha/kohadev/plack-error.log
      
          The following errors are triggered at the end of the log file:
              Use of uninitialized value in array element at
              /home/vagrant/kohaclone/tools/batch_records_ajax.pl line 50.
              Use of uninitialized value $results_per_page in numeric eq (==) at
              /home/vagrant/kohaclone/tools/batch_records_ajax.pl line 53.
              Use of uninitialized value in uc at
              /home/vagrant/kohaclone/C4/ImportBatch.pm line 1120.
      
      2) Run the following on a kohadevbox:
          exit
          git bz apply 19937
          restart_all
          sudo koha-shell -c bash kohadev
          prove t/db_dependent/www/batch.t
          cat /var/log/koha/kohadev/plack-error.log
      
          The log file will end with the restarting of plack, not the
          errors.
      
      3) run koha qa test tools
      Signed-off-by: Lee Jamison's avatarLee Jamison <ldjamison@marywood.edu>
      Signed-off-by: default avatarMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
      Amended handling of $results_per_page.
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      35249256
  3. 15 Aug, 2017 2 commits
    • Marcel de Rooy's avatar
      Bug 19049: [QA Follow-up] Mock config, default format · a423fcff
      Marcel de Rooy authored
      As requested by QA:
      [1] Mock_config enable_plugins in the test.
      [2] Fallback to MARC when format is empty. Remove die statement.
      Added:
      [3] Remove $marc. This variable got obsolete during development.
      [4] Add test on $input_file and $plugin_class. Test $text before calling
          Handler or processing $text. No need to split undef if somehow Handler
          returned undef, etc. If the routine returns an empty arrayref,
          stage-marc-import will do fine.
      Signed-off-by: default avatarMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      a423fcff
    • Marcel de Rooy's avatar
      Bug 19049: Fix regression on stage-marc-import with to_marc plugin · d24568b6
      Marcel de Rooy authored
      Bug 12412 added the use of to_marc plugins allowing arbitrary file formats
      in stage-marc-import (as long as the plugins can handle them). The feature
      was not very visible in the code, and when bug 10407 added the marcxml
      format, it made some changes that broke the use of to_marc.
      
      This patch restores the functionality by:
      [1] Adding a sub RecordsFromMarcPlugin to ImportBatch.pm, specifically
          addressing the conversion from arbitrary formats to MARC::Record.
          The original to_marc interface is used: pass it the file contents,
          and it returns a string consisting of a number of MARC blobs separated
          by \x1D.
          Consequently, the call of to_marc is removed from routine
          BatchStageMarcRecords where it did not belong. The to_marc_plugin
          parameter is removed and two calls are adjusted accordingly.
      [2] Instead of a separate combo with plugins, the format combo contains
          MARC, MARCXML and optionally some plugin formats.
      [3] The code in stage-marc-import.pl now clearly shows the three main
          format types: MARC, MARCXML or plugin based.
      
      Note: This patch restores more or less the situation after bug 12412, but
      I would actually recommend to have the to_marc plugins return MARC::Record
      objects instead of large text strings. In the second example I added a
      to_marc plugin that actually converts MARC record objects to string format,
      while RecordsFromMarcPlugin reconverts them to MARC::Records.
      
      Test plan:
      See second patch.
      Signed-off-by: default avatarMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
      Signed-off-by: Katrin Fischer's avatarKatrin Fischer <katrin.fischer.83@web.de>
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      d24568b6
  4. 10 Jul, 2017 1 commit
  5. 29 May, 2017 3 commits
  6. 13 Apr, 2017 1 commit
  7. 03 Mar, 2017 1 commit
  8. 12 Sep, 2016 1 commit
    • Marcel de Rooy's avatar
      Bug 6852: Staged import reports wrong success for items · 48aba153
      Marcel de Rooy authored
      If we import items that have a wrong branch code, the items will not
      be imported but manage-marc-import reports them as imported. (A wrong
      branch code probably occurs most, but other causes are possible too.)
      
      The underlying cause is that AddItem does not look at the error
      returned from _koha_new_item in Items.pm.
      
      This patch deals with that omission in the most economical way. It adjusts
      AddItem so that it returns undef if no item was added.
      In ImportBatch.pm I check if an item was added and adjust the totals
      accordingly instead of just always counting them.
      
      Note: Several scripts like additem.pl use AddItemFromMarc to call
      AddItem. They do not report an error, but fail silently. With this patch,
      these scripts get undef and will still fail silently. (No change.)
      Adding error checks around calls of AddItemFromMarc is outside the scope of
      this report. Here we are taking care of correct imported item numbers.
      
      Test plan:
      [1] Verify that additem.pl still works by adding a new item.
      [2] Run t/db_dependent/Items.t
      [3] Add a new branchcode, say XXX.
      [4] Pick a biblio record with a few items (n) and set one item to branch XXX.
      [5] Export this biblio with items to a MARC file.
      [6] Change the XXX item to the original branch and remove branch XXX.
      [7] Import the MARC file. Verify that one item was not imported and that
          the number of imported items reflects that (equals n-1).
      Signed-off-by: default avatarOwen Leonard <oleonard@myacpl.org>
      Signed-off-by: default avatarKatrin Fischer  <katrin.fischer@bsz-bw.de>
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      48aba153
  9. 02 Sep, 2016 2 commits
  10. 26 Aug, 2016 1 commit
  11. 08 Jul, 2016 1 commit
    • Aleisha Amohia's avatar
      Bug 9259: Ability to delete a staged file once it has been cleaned · 08e448ee
      Aleisha Amohia authored
      To test:
      1) Go to Tools -> Staged MARC Management and clean a file. If you have no files to clean, go to 'Stage MARC for import' and upload one to clean following the necessary steps.
      2) Confirm that once the file has been cleaned, the Action column now shows a Delete button. Confirm this button only shows for cleaned files.
      3) Click the Delete button.
      4) Confirm that clicking Cancel exits the pop-up message and does not delete the file.
      5) Confirm that clicking OK refreshes the list of staged records and the one you just deleted is no longer on it (has been deleted). You can confirm this by checking for the file in mysql (SELECT * FROM import_batches WHERE import_batch_id = X;)
      6) Run prove -v t/db_dependent/ImportBatch.t (have written unit tests for CleanBatch and DeleteBatch)
      
      Sponsored-by: Catalyst IT
      Signed-off-by: default avatarLiz Rea <liz@catalyst.net.nz>
      Catalyst sign off, so needs another one but YAY this is great.
      Signed-off-by: Wm. Nick Clemens's avatarNick Clemens <nick@bywatersolutions.com>
      Signed-off-by: joubu's avatarJonathan Druart <jonathan.druart@bugs.koha-community.org>
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      08e448ee
  12. 07 Apr, 2016 1 commit
  13. 24 Mar, 2016 3 commits
  14. 28 Sep, 2015 2 commits
  15. 04 May, 2015 1 commit
    • Kyle M Hall's avatar
      Bug 12412: Add ability for plugins to convert arbitrary files to MARC from record staging tool · ca167b32
      Kyle M Hall authored
      Many libraries would like to be able to import various types of files as
      MARC records ( citations, csv files, etc ). We can add a new function to
      the plugins system to allow that kind of behavior at a very custom
      level.
      
      Test Plan:
      1) Ensure you have plugins enabled and configured correctly
      2) Installed the attached version 2.00 of the Kitchen Sink plugin
      3) Download the attached text file
      4) Browse to "Stage MARC records for import"
      5) Select the downloaded text file for staging
      6) After uploading, you should see a new area "Transform file to MARC:",
         select "Example Kitchen-Sink Plugin" from the pulldown menu
      7) Click 'Stage for import"
      8) Click 'Manage staged records"
      9) You should now see two new MARC records!
      Signed-off-by: Aleisha Amohia's avatarAleisha <aleishaamohia@hotmail.com>
      Signed-off-by: Katrin Fischer's avatarKatrin Fischer <Katrin.Fischer.83@web.de>
      Works as described - interesting new feature.
      Signed-off-by: Tomas Cohen Arazi's avatarTomas Cohen Arazi <tomascohen@gmail.com>
      ca167b32
  16. 20 Apr, 2015 1 commit
  17. 16 Apr, 2015 1 commit
  18. 09 Apr, 2015 1 commit
    • Jacek Ablewicz's avatar
      Bug 10906 - Reimported records into Koha are imported only as DEFAULT... · 7c2fad1b
      Jacek Ablewicz authored
      Bug 10906 - Reimported records into Koha are imported only as DEFAULT frameworks, not what they were originally
      
      Existing framework code is currently not retained when local record
      gets replaced during batch import, or when the restore/reverse function
      is being used.
      
      This patch fixes aforementioned issues by correcting outdated GetBiblio()
      calls in C4/ImportBatch.pm
      
      To test:
      
      1/ try to replicate the issue: import some MARC records with
      "Tools -> Stage MARC records for import" etc., using test setup,
      matching rules and so on such that some existing records will get
      replaced with imported ones
      2/ observe that records replaced during import now open in the editor
      with 'Default' framework, even if they have some other framework
      set up previously
      3/ apply patch
      4/ redo 1/, confirming that this problem is no longer replicable
      5/ try use 'restore' function with some freshly imported
      records, ensure that original framework code got retained
      in the records which had their imports reverted
      
      NOTE: I confirmed this change by
      1) git grep "=\s*GetBiblio\s*("
         -- this shows how GetBiblio is called elsewhere.
            It differed! So then...
      2) vi C4/Biblio.pm
         /sub GetBiblio
         -- find the right one, notice it only returns a HASH ref,
            not an array.
      Signed-off-by: Mark Tompsett's avatarMark Tompsett <mtompset@hotmail.com>
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      Signed-off-by: Tomas Cohen Arazi's avatarTomas Cohen Arazi <tomascohen@gmail.com>
      7c2fad1b
  19. 15 Jan, 2015 1 commit
  20. 31 Oct, 2014 2 commits
  21. 19 Apr, 2014 1 commit
    • Fridolyn SOMERS's avatar
      Bug 11254: make reservoir search normalize ISBNs · cac06afe
      Fridolyn SOMERS authored
      When importing records, the ISBN is normalized and stored
      into database (see C4::ImportBatch::_add_biblio_fields).  But when
      searching with ISBN into reservoir, it is not normalized
      (see C4::Breeding::BreedingSearch).  So search does not match.
      
      This patch adds the normalisation to reservoir search.  Also, it
      replaces call private method _isbn_cleanup by GetNormalizedISBN,
      the correct public method.  Also allows the reservoir search
      on ISBN with hyphens.
      
      This is intended to fix only reservoir searches.
      
      Revised Test plan
      -----------------
       1) Back up DB
       2) Save copy of attached example somewhere findable
       2) Home -> Tools -> Stage MARC records for import
       3) Click Browse and select the example MARC file
       4) Click Upload file
       5) Tweak as desired then click Stage for import
       6) Click Manage staged records
       7) Click Import this batch into the catalog
       8) Home -> Cataloging
       9) In the Cataloging search text box type 978-0-691-14289-0 and
           click Submit
          -- ISBN13 with hypens not found in reservoir
      10) In the Cataloging search text box type 9780691142890 and
           click Submit
          -- ISBN13 without hypens not found in reservoir
      11) In the Cataloging search text box type 0-691-14289-0 and
           click Submit
          -- ISBN10 with hypens not found in reservoir
      12) In the Cataloging search text box type 0691142890 and
           click Submit
          -- ISBN10 without hypens found in reservoir
      13) Apply patch
      14) Repeat steps 9-12, this time it is always found! :)
      Signed-off-by: Mark Tompsett's avatarMark Tompsett <mtompset@hotmail.com>
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      cac06afe
  22. 13 Mar, 2014 1 commit
    • Kyle M Hall's avatar
      Bug 11923: fix option to sort contents of MARC record batches by citation descending · 183d4a55
      Kyle M Hall authored
      When the ability to stage authority records was added to Koha, sorting
      record batches by citation ( i.e. title ) caused the addition of
      "authorized_heading" to be added to the sort. When sorting by title
      descending, this causes the order by clause to be "title,
      authorized_heading DESC" which means sort by title ASC, then
      authorized_heading DESC. This is incorrect and causes regular biblio
      batches to always be sorted ascending.
      
      Test plan:
      1) Stage a batch of biblio records from a file
      2) View the staged batch
      3) Attempt to sort by title descending
      4) Note it is still sorted by title ascending
      5) Apply this patch
      6) Note the sorting now works correctly
      Signed-off-by: default avatarOwen Leonard <oleonard@myacpl.org>
      Signed-off-by: default avatarMarcel de Rooy <m.de.rooy@rijksmuseum.nl>
      Works as advertised. The code pertaining to sorting in routine
      GetImportRecordsRange will probably not win beauty prizes.
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      183d4a55
  23. 10 Mar, 2014 2 commits
    • Kyle M Hall's avatar
      Bug 10558 [QA Follow-up] · 0713f3bf
      Kyle M Hall authored
      This patch addresses a number of issues with the main patch:
      
      - regression on bug 2060 (i.e., displaying authority import batches
        correctly)
      - regression on bug 10170 (translation of import record states)A
      - use of datatables.inc
      - lack of clarity as to the licensing of tools/batch_records_ajax.pl
      - insufficent sanitizing of input used to generate an SQL statement
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      0713f3bf
    • Kyle M Hall's avatar
      Bug 10558 - Convert records table in manage-marc-import.pl to Ajax DataTable · 4d324216
      Kyle M Hall authored
      Some libraries would like to sort by columns for the records of an
      import batch. This seems like a good use of Ajax DataTables.
      
      Test plan:
      1) Apply this patch
      2) Import a record batch into Koha
         a) Use some form of matching
         b) Have some records that will match and some that won't
         c) Have at least 30 records so you can test the pager
      3) Verify the new table is functionally equivalent to the old static one
      Signed-off-by: default avatarOwen Leonard <oleonard@myacpl.org>
      
      Tests fine and looks good with the exception of the corrections I put in
      a follow-up.
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      4d324216
  24. 31 Oct, 2013 2 commits
    • joubu's avatar
      Bug 8015: (follow-up) trap exceptions thrown by SetUTF8Flag() · 0a176d46
      joubu authored
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      Signed-off-by: default avatarLeila <koha.aixmarseille@gmail.com>
      
      Bug 8015: Catch error in the SetUTF8Flag routine
      
      The eval avoids the interface to run endlessly if an error occurred.
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      Signed-off-by: default avatarLeila <koha.aixmarseille@gmail.com>
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      0a176d46
    • Kyle M Hall's avatar
      Bug 8015: Add MARC Modifications Templates · 622430cf
      Kyle M Hall authored
      The MARC Modification Templates system gives Koha users
      the power to make alterations to MARC records automatically
      while staging MARC records for import.
      
      This tool is useful for altering MARC records from
      various venders work with your MARC framework.
      
      The system essentially allows one to create a basic script
      using actions to Copy, Move, Add, Update and Delete fields.
      
      Each action can also have an optional condition to check
      the value or existance of another field.
      
      The Copy & Move actions also support Regular Expressions,
      which can be used to automatically modify field values during the
      copy/move. An example would be to strip out the '$' character
      in field 020$c.
      
      Furthermore, the value for an update can include variables
      that change each time the template is used. Currently,
      the system supports two variables, __BRANCHCODE__ which
      is replaced with the branchcode of the library currently
      using the template, and __CURRENTDATE__ which is replaced
      with the current date in ISO format ( YYYY-MM-DD ).
      
      At its simplist, it can perform functions such as:
      Copy field 092$a to 952$c
      At its most complex it can run actions like:
      Copy field 020$c to 020$c using RegEx s/\$// if 020$c equals RegEx m/^\$/
      Signed-off-by: default avatarLeila <koha.aixmarseille@gmail.com>
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      622430cf
  25. 30 Oct, 2013 4 commits
    • Kyle M Hall's avatar
    • Kyle M Hall's avatar
      Bug 7131: (follow-up) allow overlaying by barcode · 805bec0a
      Kyle M Hall authored
      This patch adds the ability to overlay by either itemnumber,
      or barcode. Itemnumbers take precendence over barcodes, which
      allows us to batch update item barcodes with an overlay.
      
      Test Plan:
      1) Create a new record with 2 items, make sure to give it a unique ISBN
      2) Download the record as MARCXML
      3) Edit the MARC XML
         a) Delete one of the two items
         b) Change the barcode in the barcode field to something unused
      4) Transform the xml file into marc with xml2marc
      5) Browse to 'Stage MARC records for import'
      6) Upload the binary marc file
      7) Choose the following options:
          Record matching rule: ISBN
          Action if matching record found: Ignore incoming record
          Action if no match is found: Ignore incoming record
          Check for embedded item record data: Yes
          How to process items: Replace items if matching bib was found
      8) Click 'Stage for import' button
      9) Verify a matching record was found, then click 'Manage staged records' link
      10) Verify the rules are still set correctly
      11) Click 'Import this batch into the catalog'
      12) The import should tell you:
          1 record was ignored
          1 item was replaced
      13) View the record details and verify the item's barcode was replaced
          with your updated barcode value
      14) Download the record as MARCXML
      15) Edit the MARC XML
          a) Delete one of the two items
          b) Delete the itemnumber field for the remaining item
          c) Alter the item's callnumber to a new value
      16) Repeat steps 4 through 12
      17) View the record details and verify the item's callnumber was replace
          with your updated callnumber value
      Signed-off-by: default avatarHenry Bankhead <hbankhead@losgatosca.gov>
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      805bec0a
    • Kyle M Hall's avatar
    • Elliott Davis's avatar
      Bug 7131: teach MARC import how to overlay items · 1dba9c64
      Elliott Davis authored
      When staging biblios with items attached you previously had only two
      options, add or don't add.
      
      This patch adds a third option to replace an item record if a match is
      found on itemnumber or barcode, else it adds the item.
      
      Test Plan:
      1) Stage a file of biblios with items attached.
      2) Import the batch into the catalog.
      3) Run the indexer so the matcher will match
      4) Modify the item data for at least one bib in the file
      5) Re-stage the file with the item matching option set to "Replace
         items if matching bib was found"
      6) Let the indexer run again
      7) You should see updated item information after the overlay
      Signed-off-by: default avatarKyle M Hall <kyle@bywatersolutions.com>
      Signed-off-by: default avatarHenry Bankhead <hbankhead@losgatosca.gov>
      Signed-off-by: Galen Charlton's avatarGalen Charlton <gmc@esilibrary.com>
      1dba9c64
  26. 19 May, 2013 1 commit
  27. 22 Apr, 2013 1 commit