And a follow up patch

This sounds like it only works in acquisitions ... can you not batch modify bib records any other way?

Okay I have applied both patches and it works beautifully for me. I'm not signing off though cause Owen is having issues and I want a third person to test to confirm that it actually works.

I do have a design suggestion - on the confirmation page after the edit is done the titles should be linked (/cgi-bin/koha/tools/batchedit.pl?bib_list=1/2/)

I also think there should be a link on the batch edit page to view the marc preview pop up so you can confirm that you have the right bib records.

Finally, I need pointers on what to put in the 'conditional' section because I didn't test that cause I didn't know what it was asking for.

what permissions are required for this to work? I was logged in as super librarian for my first tests. When I logged in with only items_batchmod permissions I got the following error:


Software error:

Can't use string ("batchedit") as a HASH ref while "strict refs" in use at /home/nengard/kohaclone/C4/Auth.pm line 1559.

For help, please send mail to the webmaster (webmaster@debian), giving this error message and the time and date of the error.


I don't see a batchedit permission anywhere.

> Can't use string ("batchedit") as a HASH ref while "strict refs" in use at
> /home/nengard/kohaclone/C4/Auth.pm line 1559.

Even with a "batchedit" permission in my database I get the same error. module_bit: 13, code: 'batchedit'

IRC Log on this topic:



[08:57]  <nengard> i'm logged in a superlibrarian
[08:58]  <nengard> i'll go ahead and try with only the edit permissions
[09:00]  <oleonard> Hmmm, no I see the batchedit permission in my database
[09:00]  <nengard> i don't have that either - but the patch doesn't say it adds
a new permission
[09:00]  <oleonard> ...and it's checked in my permissions setup
[09:00]  <nengard> oh
[09:00]  <nengard> under what?
[09:01]  <oleonard> At first I thought it would be under cataloging, but it's
under tools
[09:01]  <nengard> under tools i have items_batchmod
[09:01]  <nengard> but not batchedit
[09:02]  <oleonard> I ought to trash this database and start over... I'm not
good about keeping it "clean" when testing
[09:03]  <nengard> :)
[09:03]  <nengard> paul_p can you take a look at questions on bug 5725
[09:03]  <huginn> Bug
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5725 enhancement,
PATCH-Sent, ---, paul.poulain, ASSIGNED, Batch modifications for Biblios
[09:03]  <kf> only a thought: but do we need different permissions for
items_batchedit and biblio_batchedit?
[09:05]  <nengard> i think we do
[09:05]  <nengard> but right now we don't have one
[09:05]  <nengard> i'd argue that if you're allowed to edit the catalog then
you should be able to do batch edits ... but others might disagree
[09:06]  * oleonard does
[09:06]  <oleonard> A batch edit is potentially much more destructive
[09:06]  <oleonard> No reason not to include a separate permission and let the
supervisor decide.
[09:10]  <oleonard> nengard: I'll bet the batchedit permission didn't make it
into the patch because of the way rangi is putting together the patches
[09:11]  <oleonard> He probably didn't cherry-pick that part (if cherry pick is
the right word here)
[09:11]  <nengard> so there is a permission in another patch?
[09:13]  <oleonard> Yes, I see it in the original Biblibre branch
[09:13]  <oleonard> That must be why I have it... messy database.
[09:13]  <oleonard> But that doesn't explain why it didn't work for me even
though that permission was there
[09:21]  <oleonard> It seems strange that someone could have batch edit
permission and not catalog edit permission
[09:30]  <sekjal> I'd agree that if you can edit in batch, you should be able
to edit individually
[09:34]  <kf> so it should be grouped into the cataloging rights?
[09:37]  <oleonard> How deep can the permissions hierarchy go? Right now we
only have two levels
[09:38]  <oleonard> Theoretically you'd want "batchedit" to be a sub-permission
of "edit_catalogue" (not "editcatalog," the parent category)
[09:39]  <kf> oleonard: perhaps even the batch item delete/modify should moved
to cataloging?
[09:39]  <kf> i think they are under tools, because we have no cataloging start
page?
[09:39]  <paul_p> nengard, seen you msg. Could you drop me a mail pls, i'll
forget...
[09:39]  <nengard> okey dokey
[09:40]  <oleonard> kf: I think so. I think that grouping reflects where to
find the tool in Koha, but really the permissions should reflect roles
[09:40]  <kf> hm. I think we only have kind of a start page for circ and tools?
[09:40]  <kf> perhaps we should think about that too - tools gets crowdy
[09:40]  <kf> crowded?
[09:40]  <oleonard> Crowded.
[09:40]  <nengard> I don't mind where the batch edit is located - it is a tool
- but the permissions should be in the logical spots

(In reply to comment #4)
> This sounds like it only works in acquisitions ... can you not batch modify bib
> records any other way?

does comment 5 means this question is no more relevant ?

(In reply to comment #6)
> what permissions are required for this to work? I was logged in as super
> librarian for my first tests. When I logged in with only items_batchmod
> permissions I got the following error:
> 
> 
> Software error:
> 
> Can't use string ("batchedit") as a HASH ref while "strict refs" in use at
> /home/nengard/kohaclone/C4/Auth.pm line 1559.
> 
> For help, please send mail to the webmaster (webmaster@debian), giving this
> error message and the time and date of the error.
> 
> 
> I don't see a batchedit permission anywhere.

oups, you're right, is must be tools => batchedit (it's a subperm of tools)

sending patch immediatly

(In reply to comment #9)
> (In reply to comment #4)
> > This sounds like it only works in acquisitions ... can you not batch modify bib
> > records any other way?
> 
> does comment 5 means this question is no more relevant ?

Yes, I found it :)

I tried to apply this patch on top of the other two and it did not apply.  Either there is a problem with the patch - or with the way I applied it:

Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying: BG5725 follow-up : permission is wrong
fatal: sha1 information is lacking or useless (tools/batchedit.pl).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 BG5725 follow-up : permission is wrong
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
nengard@debian:~/kohaclone$

Making an unified patch, to replace these three, will upload shortly

Unified patch applies, but when logged in as a superlibrarian the changes I made to the bib record didn't take. I didn't have any errors, it just said everything was OK but when I view the marc those fields aren't there.

I suspect nicole comment #15 is fixed by the follow-up, nicole, pls check

When I choose 'batch edit' it chooses all the items in my cart regardless of which ones I checked before I clicked 'batch edit' it should only batch edit the ones I choose for it to batch edit.

also the second patch does not apply:


Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y
Applying: BG5725 follow-up : permission is wrong
fatal: sha1 information is lacking or useless (tools/batchedit.pl).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 BG5725 follow-up : permission is wrong
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
nengard@debian:~/kohaclone$

This bug is mentioned in:
Bug 5725 : MT #2991 (Feature) Batch biblio	modifications http://lists.koha-community.org/pipermail/koha-patches/2011-February/013791.html
Bug 5725 follow up http://lists.koha-community.org/pipermail/koha-patches/2011-February/013794.html
Bug 5725 follow up http://lists.koha-community.org/pipermail/koha-patches/2011-February/013801.html
Bug 5725 follow up http://lists.koha-community.org/pipermail/koha-patches/2011-February/013802.html
Bug 5725 follow up http://lists.koha-community.org/pipermail/koha-patches/2011-February/013803.html
Bug 5725 follow up http://lists.koha-community.org/pipermail/koha-patches/2011-February/013804.html
Bug 5725 : Batch Modifications for Biblios http://lists.koha-community.org/pipermail/koha-patches/2011-February/013911.html

*** Bug 5435 has been marked as a duplicate of this bug. ***

It doesn't work for me.
Tested:
 - Add biblios to my cart, show my cart, and click on "Batch Edit"
    Nothing happens, except that all biblios in my cart disappear.
 - Go directly to tools/batchedit.pl
    It appears that it works (Status 'OK') but the biblios aren't modified.

Moreover the title page of batchedit.pl is "Batch Deletion of Items" which is clearly not good.

OK, after creating "batchedit" permission, the first problem disappear, but problems discussed in comment 15 and comment 18 are still there.

Two questions:

1 - First, there is a new patch should the status be changed to 'needs sign off' or is that patch something else?

2 - Does this feature allow for the finding and replacing of specific strings in a marc field?

Nicole

Some comments before I even test this patch's functionality:

- This patch includes an explicit DB revision number and a revision to a previous section ($DBversion = "3.05.00.004";). 
- The patch includes a revision to kohaversion.pl which I understood should be left to the RM?
- The patch appears to contain the entirety of the changes proposed in Bug 5887. If this is correct, Bug 5887 should be closed as it is redundant.

Some notes on testing:

- This patch does not add a link to the batch edit interface from the tools page.
- The interface says you can use a file, but it does not specify what information the file should have.
- The same is true of the "enter records one by one" option. It says "Records numbers list," but it's not explicit what kind of numbers it needs.
- I like that the batch item edit/delete process lets me submit my batch of items *before* specifying the changes. That gives me a chance to preview the set of records which will be modified. I think this is an essential step to prevent unwanted edits.
- The results screen (after submission) uses a yellow "alert" style message box to display "All operations processed." This is informational, so it should use the "message" style box. It should also appear at the top of the page, not the bottom.
- The results screen listing of modified records should link to each record.
- The results screen has a "status" column heading but no data in the subsequent rows.
- The first test I did was to select a couple of records and try to modify the 000 tag with new data, but the records remained unchanged after submission even though the interface reported no errors.

(In reply to comment #29)
> Some notes on testing:
> 
> - This patch does not add a link to the batch edit interface from the tools
> page.

fixed in follow-up

> - The interface says you can use a file, but it does not specify what
> information the file should have.

Fixed some wording

> - The same is true of the "enter records one by one" option. It says "Records
> numbers list," but it's not explicit what kind of numbers it needs.

fixed wording too

> - I like that the batch item edit/delete process lets me submit my batch of
> items *before* specifying the changes. That gives me a chance to preview the
> set of records which will be modified. I think this is an essential step to
> prevent unwanted edits.

It was already the case when you reached this page from the cart page, so it was quite easy to do it from other origins.

> - The results screen (after submission) uses a yellow "alert" style message box
> to display "All operations processed." This is informational, so it should use
> the "message" style box. It should also appear at the top of the page, not the
> bottom.

fixed

> - The results screen listing of modified records should link to each record.

Not fixed. I propose to do an ENH for later

> - The results screen has a "status" column heading but no data in the
> subsequent rows.

Was a HTP => TT switch glitch

> - The first test I did was to select a couple of records and try to modify the
> 000 tag with new data, but the records remained unchanged after submission even
> though the interface reported no errors.

I think it's because you forgot to click "add" (on the right of the action form). You must click add even if you have just one condition.

Back to needs signoff, let me know what you think

owen, it would be good to have this in 3.6, could you take care of signing-off the follow-up & mark signed-off if it's ready ?

Still having problems with modifications to 000. Here's the error I'm getting now:

substr outside of string at /usr/share/perl5/MARC/Record.pm line 571.
 at /usr/share/perl5/MARC/Record.pm line 571
	MARC::Record::set_leader_lengths('MARC::Record=HASH(0xa773568)', 651, 253) called at /usr/share/perl5/MARC/File/USMARC.pm line 313
	MARC::File::USMARC::encode('MARC::Record=HASH(0xa773568)') called at /usr/share/perl5/MARC/Record.pm line 473
	MARC::Record::as_usmarc('MARC::Record=HASH(0xa773568)') called at /home/oleonard/kohaclone/C4/Biblio.pm line 3511
	C4::Biblio::ModBiblioMarc('MARC::Record=HASH(0xa773568)', 2, '') called at /home/oleonard/kohaclone/C4/Biblio.pm line 339
	C4::Biblio::ModBiblio('MARC::Record=HASH(0xa773568)', 2, '') called at /home/oleonard/kohaclone/tools/batchedit.pl line 201

If you submit a follow up can you please rebase the other patches and squash them with the new one?  Thanks!

Owen, i've investigated, I think the problem is due to the fact that you tried to set a value that is too short.
If you try to set a leader smaller than the official size, MARC::Record will complain because he tries to set some values, that he can't. The line you've got is :
    substr($self->{_leader},10,2) = '22';
MARC::Record tries to set 22 in position 10 and 11, and the string you've submitted is probably less than 10, so the substr result in the message you get.

We have two options :
* remove the 000
* specify in the doc (Nicole, it's for you !) that updating the leader must be made carefully, with a full leader, some positions being ignored automatically and set to the default MARC values (positions 0-4 with the length of the record for example)

You preference ?

(In reply to comment #41)
> You preference ?

Sorry to have not immediately replied to your question. I don't think it's true that I have tried to set a value that is too short--at least not by the standards of the MARC editor itself. I tested using a value that the MARC editor accepted.

However, I don't think the 000 problem should prevent this from being approved. Let's hide 000 as an option if we must, in order to get this into master.

It's not clear to me how to add a whole new tag. 

Field [650], Subfield [Whole field], Action [Create field and subfield] ?

What do I put in value? How does it know which subfield I'm adding?

(In reply to comment #46)
> It's not clear to me how to add a whole new tag. 
> 
> Field [650], Subfield [Whole field], Action [Create field and subfield] ?
> What do I put in value? How does it know which subfield I'm adding?

The 'whole field' is meaningless in the case of "adding field & subfield". You must choose the subfield to add. It means that you can add only one subfield at a time.
If you must add a field with subfields you must do that in more than 1 step :
 * step 1 = add field and a subfield
 * step 2+= add subfield to the freshly created field

What's the use of "whole field" then ? It's only usefull in the case of <010 field (where there is no subfield). I'll submitt a follow-up to remove it when not applicable

Something I didn't notice before: It doesn't seem you can set indicators. So if I want to create a new 650 tag and add it to a batch of records the resulting addition looks like this:

=650  \\$aFiddle tunes

When, AFAIK, it should look like this:

=650  \0$aDivorced people

Also, weren't we going to hide the option to modify 000 since it wasn't working?

With no information provided about how the "condition" option works, I think users are going to be surprised at how it works. For instance, I tried a modification with these settings:

100 | a | Modify subfield | Chase, Truddi. | Chase, Trudy.

...and the tool correctly modified only the record where 100a = "Chase, Truddi.".

Then, wondering how the conditional works I tried:

100 | a | Modify subfield | Sparks | Sparks, Nicholas M.

...and the tool found records where 100a contained "Sparks" and replaced only the value I had put into the conditional. The resulting 100a value was "Sparks, Nicholas M., Nicholas."

I can see how this would be a very powerful aspect of the tool, but it should be made clear somehow what the user should expect from it.

Updating Version : This ENH will be for Koha 3.8

Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)

I wanted to give it a try in order to see what can be done on the documentation side so that this patch passe QA but it doesn't apply :

Applying: Suggested change to Bug 5725 - Batch modifications for Biblios
error: patch failed: koha-tmpl/intranet-tmpl/prog/en/js/basket.js:434
error: koha-tmpl/intranet-tmpl/prog/en/js/basket.js: patch does not apply
error: patch failed: koha-tmpl/intranet-tmpl/prog/en/modules/basket/basket.tt:86
error: koha-tmpl/intranet-tmpl/prog/en/modules/basket/basket.tt: patch does not apply

Patch rebased (& tested, seems to work)

Just tried to test it. Patch doesn't apply.

error: patch failed: C4/Biblio.pm:3876
error: C4/Biblio.pm: patch does not apply

At the functional level there is not a duplicate with the 8015 bz ?.....

(In reply to comment #63)
> At the functional level there is not a duplicate with the 8015 bz ?.....

I dont think so, that is allowing you to modify the records on import (via staging).

This one is about batch modifying existing biblios. (Like the batch modify for items we have).

Created attachment 11731 [details] [review]
Bug 5725 : Batch Modifications for Biblios

commit 66282fed94564969f0368e27c7231116a2d1c0fe
Author: Chris Cormack <chrisc@catalyst.net.nz>
Date:   Tue Feb 22 08:43:24 2011 +1300

    Bug 5725 : Follow up fixing permissions thanks to Paul Poulain

commit 4d0241aea5be13b00abbc6100dc98ec87f816081
Author: Paul Poulain <paul.poulain@biblibre.com>
Date:   Mon Jan 10 17:22:31 2011 +0100

    Bug 5725 follow up

    Owen noticed the batchedit was not working. This was because we made a patch months ago to change the GetBiblio API
    (the 1st returned arg is useless)
    This patch is not in main trunk, resulting in the error owen has noticed.

    This patch goes back to official API (even if it is clumsy : the patch we did does not apply anymore)

commit 19b3e0ecc57af1c2151340328bf06e26882b7863
Author: Paul Poulain <paul.poulain@biblibre.com>
Date:   Wed Dec 15 20:47:21 2010 +0100

    Bug 5725 : MT #2991 (Feature) Batch biblio modifications

    This patch add a new feature of batch biblio modifications,
    it permit to select biblios from basket, and modify fields of them setting

    Rebased to fix whitespace issues.

Bug 5725 follow-up Fixes adresses comments 28 and 29 (from Owen)

* add a link to tools-home
* display the biblios before defining rules
* add some help/change some wording
* fixes result "Status" column (was a H:T:P => T:T glitch) and put the message on the top

I also removed an unused variable

Bug 5725 follow-upd, deal with leader

As Owen comment 33 notices, leader update was not working. This patch fixes the problem (and fix a few reindenting glitches as well)

Additional fixes for Bug 5725 - Batch modifications for Biblios

- Correcting page title
- Adding breadcrums
- Adding sidebar menu (matching other batch mod pages)
- Showing "loading" graphic during AJAX operations
- Adding empty option to list of MARC tags so that onchange event
  will fire when the user is choosing 000
- Other structural markup changes

http://bugs.koha-community.org/show_bug.cgi?id=5727

Created attachment 11732 [details] [review]
BZ5725 follow-up for comment 48

This small follow up:
  * removes "whole field" in subfield list except when dealing with a field <010 (that has no subfield)
  * add a missing string resulting in an "undefined" when user choosed 'Create field and subfield' and hit Add button
  * synch the description after adding with the description in the list box of the 4 options available
  * fixes indentation a little

Created attachment 11733 [details] [review]
Suggested change to Bug 5725 - Batch modifications for Biblios

This modification changes the "Batch edit" button to a link
in the "Selected items: " set alongside "add to a list," "place
hold," etc. Instead of always batch editing all items, the user
can select individual ones to be passed to the batch edit page.

Conflicts fixed, patches now all apply on master

i test in a sandbox

i try to delete a subfield(200$e) but i have no change in the bibliographic records....

I tested this and found that when I clicked "batch edit" from the cart the batchedit.pl page would load with a list of entries that read "no title," linking to /cgi-bin/koha/catalogue/detail.pl?biblionumber=

I noticed the same problem as Owen.

But more than that, can't this page use Marc modification template defined in Bug 8015 ? Rules in batchedit.pl seems very similar to rules defined in modification templates (Bug 8015 rules even looks more flexible)

Any chance this will make it in to 3.12.

This will be a nice improvement to 3.12.

Well it won't magically make it, unless someone addresses the problems that made it fail QA, it has no chance of making it into 3.12

This will be a nice improvement to 3.14...

If someone can repair it, we can test it next week.

I am working on a new version of this, based on bug 8015.

see bug 11395