Applying: Bug 10855: Search subscriptions by additional fields
fatal: sha1 information is lacking or useless (C4/Serials.pm).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 10855: Search subscriptions by additional fields

So I pass the status to "Failed QA".

NB. The patch "Update database entry" contains char '|' instead of char ';'.

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

against master 3.13.00.034:
Applying: Bug 10855: New fields on adding/updating a subscription
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging serials/subscription-detail.pl
Auto-merging serials/subscription-add.pl
CONFLICT (content): Merge conflict in serials/subscription-add.pl
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-detail.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-add.tt
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-add.tt
Auto-merging C4/Serials.pm
CONFLICT (content): Merge conflict in C4/Serials.pm
Failed to merge in the changes.
Patch failed at 0001 Bug 10855: New fields on adding/updating a subscription

So I pass tha patch to "Failed QA" status.

NB. Update database entry needs to be rebased too.

Thanks, Jonathan.
Applying the patch is OK.
I get this error message during step 3 of web installation:
----
The following error occurred while importing the database structure:
ERROR 1064 (42000) at line 3320: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '| CREATE TABLE `additional_field_values` ( `id` int(11) NOT NULL AUTO_IN' 
----

In installer/data/mysql/updatedatabase.pl, there a 'q' instead of 'qq' in two lines, and in kohastructure.sql the ending char of two lines is wrong [v. ENGINE=InnoDB DEFAULT CHARSET=utf8 |].
So I pass the patch to "failed QA" status.

(In reply to Paola Rossi from comment #43)
> In installer/data/mysql/updatedatabase.pl, there a 'q' instead of 'qq' in
> two lines, and in kohastructure.sql the ending char of two lines is wrong
> [v. ENGINE=InnoDB DEFAULT CHARSET=utf8 |].
> So I pass the patch to "failed QA" status.

The typo was in kohastructure.
The q syntax is valid.

against master 3.13.00.042:
Applying: Bug 10855: New fields on adding/updating a subscription
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging serials/subscription-detail.pl
Auto-merging serials/subscription-add.pl
Auto-merging C4/Serials.pm
CONFLICT (content): Merge conflict in C4/Serials.pm
Failed to merge in the changes.
Patch failed at 0001 Bug 10855: New fields on adding/updating a subscription

So I pass the patch to "Patch doesn't apply" status.

The patches are applied well against 3.13.00.042.
Test plan "prove t/db_dependent/AdditionalField.t" results in a FAIL:
t/db_dependent/AdditionalField.t .. 1/34 DBD::mysql::st execute failed: Column 'status' cannot be null at /var/root-koha/bug-10855/C4/Serials.pm line 1501.
DBD::mysql::st execute failed: Column 'status' cannot be null at /var/root-koha/bug-10855/C4/Serials.pm line 1501.
# Looks like you planned 34 tests but ran 20.
# Looks like your test exited with 255 just after 20.
t/db_dependent/AdditionalField.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 14/34 subtests 
Test Summary Report
-------------------
t/db_dependent/AdditionalField.t (Wstat: 65280 Tests: 20 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 34 tests but ran 20.
Files=1, Tests=20,  0 wallclock secs ( 0.01 usr  0.01 sys +  0.37 cusr  0.16 csys =  0.55 CPU)
Result: FAIL

So I pass the patch to "Failed QA" status.

NB. In my test case, af2 is 245, and the title of the subscribed notice is "Bulletin". Testing new fields on adding/updating a subscription, the af2 field is not filled with the specified marc field of the notice, i.e. there is no "Bulletin" on the left of the sentence "This value will be filled with the 245 subfield of the selected biblio.". Afterwards I set af2 to 245a and try again, but yet nothing appears.

(In reply to Paola Rossi from comment #53)
> NB. In my test case, af2 is 245, and the title of the subscribed notice is
> "Bulletin". Testing new fields on adding/updating a subscription, the af2
> field is not filled with the specified marc field of the notice, i.e. there
> is no "Bulletin" on the left of the sentence "This value will be filled with
> the 245 subfield of the selected biblio.". Afterwards I set af2 to 245a and
> try again, but yet nothing appears.

Last patch fixes the UT.

You have to save your subscription for filling the value linked to a marc field.

(In reply to Jonathan Druart from comment #55)
> (In reply to Paola Rossi from comment #53)
> > NB. In my test case, af2 is 245, and the title of the subscribed notice is
> > "Bulletin". Testing new fields on adding/updating a subscription, the af2
> > field is not filled with the specified marc field of the notice, i.e. there
> > is no "Bulletin" on the left of the sentence "This value will be filled with
> > the 245 subfield of the selected biblio.". Afterwards I set af2 to 245a and
> > try again, but yet nothing appears.
> 
> Last patch fixes the UT.
> 
> You have to save your subscription for filling the value linked to a marc
> field.

Thanks, Jonathan.
I apply the last patch, and now the test is OK.
Now I set the marc field to 245$a, instead of 245.
After having saved the subscription, editing the subscription once more, now the value af2 is shown as desired (OK). In serials/subscription-detail.pl?subscriptionid=X, all the fields are displayed (OK).
In subscriptions' advanced search page, all searchable additional fields are present on the form (OK).
The subscriptions' advanced search works well (OK). All the added fields have the corresponding column in the table (OK).
On the contrary, no value is displayed in these new columns of the table [so nor the description neither the code can be seen.] And searching from the bottom of these columns gives wrong results: the result is always zero.
Testing the claim page, all the columns are displayed, and now the values too (OK)! 
On the contrary, searching from the bottom of the columns works bad: nothing is found (not even the library!) in the various columns. Except in the last column (the fourth added field, in my test case): everything is always found whatever I write (KO).
So I pass the patch to "Failed QA" status.

(In reply to Paola Rossi from comment #56)
> On the contrary, searching from the bottom of the columns works bad: nothing
> is found (not even the library!) in the various columns. Except in the last
> column (the fourth added field, in my test case): everything is always found
> whatever I write (KO).

Could you confirm the filters work on master?

Paola, I find a bug on datatables filters (bug 11205). It is not introduced by these patches but maybe it will fix your issue.

(In reply to Jonathan Druart from comment #58)
> Paola, I find a bug on datatables filters (bug 11205). It is not introduced
> by these patches but maybe it will fix your issue.

Thanks, Jonathan. Applying of 11205 is OK.
In subscriptions' advanced search, yes, bug 11205 fixes the problem.
Now the filters at the bottom of columns such as "ISSN", "Title", "Library", "Expiration date", work well.
Staying that no value is displayed in the new columns of the table [so nor the description neither the code can be seen], nothing is found when I use the filters at the bottom of these columns.

In Claims, no, bug 11205 doesn't fix the problem. The use of filters at the bottom of columns such as "Vendor", "Library", "Title", "Issue number", "Status", "af1", always results in a "No matching records found" answer.
When I use the filter "From" and "To", the selection is nearby OK (range [x,y] selects "Since"' days between [x+1,y-1]).
At the bottom of the table, whereas the "Select CSV profile" is only one ("issues to claim"), selecting "Download selected claims" always results in the error:
"Please select at least one item to export".
But no checkbox is displayed in the whole page in my test case.

about comment 57:
The master 042 has not filters in CLAIMS' table.

(In reply to Paola Rossi from comment #59)
> In Claims, no, bug 11205 doesn't fix the problem. The use of filters at the
> bottom of columns such as "Vendor", "Library", "Title", "Issue number",
> "Status", "af1", always results in a "No matching records found" answer.
> When I use the filter "From" and "To", the selection is nearby OK (range
> [x,y] selects "Since"' days between [x+1,y-1]).
> At the bottom of the table, whereas the "Select CSV profile" is only one
> ("issues to claim"), selecting "Download selected claims" always results in
> the error:
> "Please select at least one item to export".
> But no checkbox is displayed in the whole page in my test case.

I asked to Julian to try to reproduce your issue. He found 2 others issues but he did not reproduce what you describe.
Did you get a JS error?

I re-installed the master again, and applied all the 13 patches.

I create a new notice, i.e. a claim notice for serials issues.
In the claim page, now table and filters are OK.
The claim notice is mandatory, otherwise the first column [of checkboxes] of the table is missing.
But koha doesn't force in the creation of this notice.

About searching subscriptions by additional fields, I hypothesize not to exclude authorized values. So selecting these 4 cases in the form results in errors:
category of the added field,"value",error:
1) CCODE,"FICTION",finds FICTION+NON FICTION
2) NOT_LOAN,"Not For Loan",finds "Ordered"
3) YES_NO,"NO",finds everything and looses the selection in form
4) HINGS_UT,"Information not available; Not applicable",find everything and looses the selection in form.
NB: Some descriptions are part of other ones in the same category (i.e. "Fiction" in "Non Fiction" of CCODE, "Lost" in "Lost and Paid For" of LOST). But "Fiction" of CCODE finds erroneously, while "Lost" of LOST finds right.

The 4 cases of errors in the form are the only errors I find now.

I pass the patch to "Failed QA" status.

(In reply to Paola Rossi from comment #63)
> 3) YES_NO,"NO",finds everything and looses the selection in form
Good catch! If the value of the authorised values is 0, the filter don't work.
I will provide a new followup.

(In reply to Jonathan Druart from comment #65)
> Created attachment 22869 [details] [review] [review]
> Bug 10855: Filtering on additional fields don't work if value is equal to 0
> 
> If you tried to filter on an additional field linked to an authorised
> value, that did not work if the value was 0.

Thanks,Jonathan.

This last patch is wrong in searching: only modified subscriptions are found now.
On the contrary, until now, advanced search found either modified subscriptions or not yet modified subscriptions.

More over updatedatabase needs to be rebased (today I've tested against 043).

I beg your pardon I didn't realize before:

A) there is an old "Advanced search" tab on the left over "Claims", on cgi-bin/koha/serials/serials-home.pl, whose form shows searchfields like "Supplier", "Branch", "EAN" (?). In the new form for advanced search they are "Vendor", "Library". I think you'd better delete the "old" tab.

B) there is an abnormal termination in modifying subscription on /cgi-bin/koha/serials/subscription-add.pl. It occurs when an additional mark field has been added, but it's an error, such as the non-existent 022$b. Koha sends this error message:
Software error:
DBD::mysql::db do failed: Column 'value' cannot be null at /var/root-koha/bug-10855/Koha/AdditionalField.pm line 107.

When a non-existent mark field is not a new one, but it's added modifying another existent mark field by Action "Edit", modifying the subscription Koha puts no value in the wrong additional field without sending error message.

So I pass the patch to "Failed QA" status.

(In reply to Paola Rossi from comment #66)

Hello Paola,

> This last patch is wrong in searching: only modified subscriptions are found
> now.
> On the contrary, until now, advanced search found either modified
> subscriptions or not yet modified subscriptions.

I am not sure to understand. You said a subscription does not appear on searching on additional fields if the subscription does not have an additional fields? If yes, it is normal, you have to edit a subscription for setting these fields. Maybe could we imagine a script for automatically filling them.

> A) there is an old "Advanced search" tab on the left over "Claims", on
> cgi-bin/koha/serials/serials-home.pl, whose form shows searchfields like
> "Supplier", "Branch", "EAN" (?). In the new form for advanced search they
> are "Vendor", "Library". I think you'd better delete the "old" tab.

Yes, I will remove it.

> B) there is an abnormal termination in modifying subscription on
> /cgi-bin/koha/serials/subscription-add.pl. It occurs when an additional mark
> field has been added, but it's an error, such as the non-existent 022$b.
> Koha sends this error message:
> Software error:
> DBD::mysql::db do failed: Column 'value' cannot be null at
> /var/root-koha/bug-10855/Koha/AdditionalField.pm line 107.

Confirmed, will be fix.

> When a non-existent mark field is not a new one, but it's added modifying
> another existent mark field by Action "Edit", modifying the subscription
> Koha puts no value in the wrong additional field without sending error
> message.

Could you detail please, I don't reproduce this issue.

(In reply to Jonathan Druart from comment #68)
> Created attachment 23052 [details] [review] [review]
> Bug 10855: Remove the advanced serial search box on the serial home page

thanks, the patch is OK

(In reply to Jonathan Druart from comment #69)
> Created attachment 23053 [details] [review] [review]
> Bug 10855: FIX an add field should not be created if the marc field does not
> exist.
> 
> This patch fixes the following:
> Create an add fields linked to a nonexistent marc field (does not exist
> in serials).
> Edit a subscription and save.
> Without this patch, an error occured:
> Software error:
> DBD::mysql::db do failed: Column 'value' cannot be null at
> /var/root-koha/bug-10855/Koha/AdditionalField.pm line 107.

thanks, tha patch is OK.

(In reply to Jonathan Druart from comment #67)
> (In reply to Paola Rossi from comment #66)
> 
> Hello Paola,
> 
> [...] you have to edit a subscription for
> setting these fields. Maybe could we imagine a script for automatically
> filling them.
> 

a script for automatically filling "mark" additional fields, and filling "category" additional fields with a value chosen among the available ones.
Perhaps it could be a script that a user can use or not, depending on the case.
And what about adding a further option "missing value" for every additional search field of the form on the left?

(In reply to Paola Rossi from comment #72)
> a script for automatically filling "mark" additional fields, and filling
> "category" additional fields with a value chosen among the available ones.
> Perhaps it could be a script that a user can use or not, depending on the
> case.

Yes, it is a good idea. But I don't plan to do in on this report. Maybe later.

> And what about adding a further option "missing value" for every additional
> search field of the form on the left?

I don't think it is really useful. What would be the use?

Hello Jonathan,

First - thank you very much for those patches; I really like the concept.
I'm currently trying to extend/adapt your solution for another table (aqorders), as suggested in here: [url]http://www.mail-archive.com/koha-devel@lists.koha-community.org/msg05550.html[/url] .
So far it's going fine, almost working now. Here and there I'm encountering some (minor) issues, though:

1) Methods in Koha/AdditionalField.pm are taking 'tablename' as an argument, but they are occasionally called with 'table' instead (in patch 22700/Search.pm, 22699/serials-search.pl, 22698, ..) which is silently ignored by package methods. This problem is only starting to manifest itself if there are additional fields for 2+ different tables being used.
2) Column 'value' in table additional_field_values is created (patch 22703) with utf8_bin collation (but only in installer/data/mysql/updatedatabase.pl, not in the installer/data/mysql/kohastructure.sql ?). I wonder if this is intentional (to make it case-sensitve)?
3) Any chances to support/allow arbitrary field names (with non-ascii characters, spaces etc.)? That will probably require an extra column (e.g. "label") in additional_fields table (?).
4) If there are non-asci / uft-8 characters involved (anywhere in the objects returned from AdditionalField.pm - in cases when offending objects are further processed with C4::Templates->output), result WWW page is prone to be garbled (partially double-encoded). This problem is similar to bug 11290; it happens because output()/utf8_arrayref()/utf8_hashref() in Templates.pm do not know what to do with blessed hashrefs - if ref() doesn't return HASH or ARRAY, they wrongly assume it's a scalar.. Like for bug 11290, adding bunch of ' |html_entity' to templates does work as an workaround for this problem, but I'm wondering if we shouldn't actually fix Templates.pm instead, that would be better/more general solution (?).

(In reply to Jacek Ablewicz from comment #74)
> Hello Jonathan,

Hello Jacek,

> 1) Methods in Koha/AdditionalField.pm are taking 'tablename' as an argument,
> but they are occasionally called with 'table' instead (in patch
> 22700/Search.pm, 22699/serials-search.pl, 22698, ..) which is silently
> ignored by package methods. This problem is only starting to manifest itself
> if there are additional fields for 2+ different tables being used.

Good catch, I will provide a followup.

> 2) Column 'value' in table additional_field_values is created (patch 22703)
> with utf8_bin collation (but only in installer/data/mysql/updatedatabase.pl,
> not in the installer/data/mysql/kohastructure.sql ?). I wonder if this is
> intentional (to make it case-sensitve)?

No, patch coming...

> 3) Any chances to support/allow arbitrary field names (with non-ascii
> characters, spaces etc.)? That will probably require an extra column (e.g.
> "label") in additional_fields table (?).

Why? There are a free field and an id, I thought it was enough.

> 4) If there are non-asci / uft-8 characters involved (anywhere in the
> objects returned from AdditionalField.pm - in cases when offending objects
> are further processed with C4::Templates->output), result WWW page is prone
> to be garbled (partially double-encoded). This problem is similar to bug
> 11290; it happens because output()/utf8_arrayref()/utf8_hashref() in
> Templates.pm do not know what to do with blessed hashrefs - if ref() doesn't
> return HASH or ARRAY, they wrongly assume it's a scalar.. Like for bug
> 11290, adding bunch of ' |html_entity' to templates does work as an
> workaround for this problem, but I'm wondering if we shouldn't actually fix
> Templates.pm instead, that would be better/more general solution (?).

Yes, I think we must have a generic solution here, not fixing templates. I submitted a patch on bug 6554.

Something seems to be not quite right with serials/serials-search.pl. When I'm searching subscriptions using regular fields - leaving additional fields inputs empty / set to 'All' for authorized ones, I'm allways getting 0 search results.

This error seems to be related to patch 22869 (added define () in line 79). After changing it this way:

79c79,80
<     if ( defined ( my $filter_value = $query->param('additional_field_' . $field->{id} . '_filter') ) ) {
---
>     my $filter_value = $query->param('additional_field_' . $field->{id} . '_filter');
>     if ( defined( $filter_value ) && $filter_value ne '' ) {

searching works again like it should. I'm not sure if that may be a proper fix, but it corrected this particular problem.

(In reply to Jonathan Druart from comment #75)

> 
> > 3) Any chances to support/allow arbitrary field names (with non-ascii
> > characters, spaces etc.)? That will probably require an extra column (e.g.
> > "label") in additional_fields table (?).
> 
> Why? There are a free field and an id, I thought it was enough.

It was enough, no need to extend additional_fields table.. Also, in case extra fields are really needed, one can always add additional fields to additional_fields using Koha::AdditionalFields ;).

I had some problems with arbitrary additional field names, because of using field names in <input name="..> and <select name=".." - my 1st tought was to solve this by adding an extra column to additional_fields table, while of course it's not necessary, when field id can be used for this purpose instead on field name.
I just noticed you allready switched from using 'name' to using 'id' in patch 22701, but only (?) for serials-search.[pl|tt].

Yet subscription-add.* script & template are (?) still using field name for <input name=""> etc. isntead of field id - that's where I encountered aftermentioned problems. Another possibility is that while applying patches I simply may have missed one (or two)..

(In reply to Jacek Ablewicz from comment #78)
Hello Jacek,
I squashed all fixes into one.

> 79c79,80
> <     if ( defined ( my $filter_value = $query->param('additional_field_' .
> $field->{id} . '_filter') ) ) {
> ---
> >     my $filter_value = $query->param('additional_field_' . $field->{id} . '_filter');
> >     if ( defined( $filter_value ) && $filter_value ne '' ) {
> 
> searching works again like it should. I'm not sure if that may be a proper
> fix, but it corrected this particular problem.

Yep, it is fine. It is included in the squashed patch.

(In reply to Jacek Ablewicz from comment #79)
> It was enough, no need to extend additional_fields table.. Also, in case
> extra fields are really needed, one can always add additional fields to
> additional_fields using Koha::AdditionalFields ;).

It would be fun but I discourage you to do that :)

> Yet subscription-add.* script & template are (?) still using field name for
> <input name=""> etc. isntead of field id - that's where I encountered
> aftermentioned problems. Another possibility is that while applying patches
> I simply may have missed one (or two)..

Yes, good catch. Fixed in the last patch too.

Thank you very much for testing!

I apply the patch against master 3.15.00.005.

Applying: Bug 10855: New fields on adding/updating a subscription
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-detail.tt
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-detail.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/serials/subscription-add.tt
Auto-merging C4/Serials.pm
Failed to merge in the changes.
Patch failed at 0001 Bug 10855: New fields on adding/updating a subscription
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".

After resolving the conflict (in subscription-detail.tt), a new conflict arises applying the following fifth patch.

So I pass the patch to "Patch doesn't apply" status.

I test the patch against master 3.15.00.006.
The 8-th patch "Update database entry" needs to be rebased.
The following errors occur.
So I pass the patch to "Failed QA" status.

I add some searchable additional fields, in particular these ones:
022$a
category NOT_LOAN
category CCODE

Using advanced "Search subscription", I see the following 2 errors:
S1) My subscription' NOT_LOAN-category-additional-field value is "Ordered" (code "-1" in Administration Authorized values' table);
choosing "NOT_FOR_LOAN" (code "1") in the search field in the left column, the list shows the subscription.
S2) My subscription' CCODE-category-additional-field value is "Non Fiction" (code "NFIC");
choosing "Fiction" (code "FIC") in the search field in the left column, the list shows the subscription.

The string "FIC" is a substring of string "NFIC", as well as the string "1" is a substring of "-1". So the error could be that search matches codes of values of the categories in a "contains" way, instead of an "exactly =" way.
The error could occur matching the codes, not the descriptions.
A counterexample is this of category "LOST": description "Lost" is a substring of description "Lost and Paid For".
The corresponding codes are "1" and "3", mutually distinct strings.
S3 OK) searching "Lost", the subscription whose additional value is set to "Lost and Paid for" is not found.

Errors filtering at the bottom of the columns of the result table (columns of additional searchable fields):
F1) My subscription' ISSN-marc-additional-field value is 12345678;
writing 12345678 in the filter at the bottom of the column, the list of subscriptions becomes null.
F2) My subscription' NOT_LOAN-category-additional-field value is "Ordered";
writing "Ordered" in the filter at the bottom of the column, the list of subscriptions becomes null.
F3) Using every filter at the bottom of the columns of the additional searchable fields, the list becomes null.
F4 OK) On the contrary, using the filters at the bottom of the fields that are not additional the list is filtered OK.

[I use FireFox 25.0.1]

NB1. A form in the left column of the page is often named "Filter" in koha. The subscription searching is named "Search" there.

NB2. Before patching the zero case, all the subscriptions were found by advanced search: either the ones modified with additional fields filled, or the ones not yet modified whose additional fields are therefore still unset. After patching the zero case, advanced search found only the modified subscriptions.

(In reply to Paola Rossi from comment #93)
Paola,
I submitted 2 new patches:
The first one fixes the issue on the exact match when a field is linked to an authorised value.
The second one fixes the filter issue (bad conflict merge).

> NB1. A form in the left column of the page is often named "Filter" in koha.
> The subscription searching is named "Search" there.

Not introduced by this patch.

Thanks, Jonathan.

[I'll read further comments after january the 7-th].

I test against master 3.15.00.007.

I test "New fields on adding/updating a subscription" and find this error.

New) A marc additional field is not automatically filled with the specified marc additional field of the notice by "New"ing subscriptions.
On the contrary, "Edit"ing subscription (i.e. modifying subscriptions) fills the marc additional fields as required.
OK: Either Newing or Editing subscriptions fill the category additional fields. 

I test "Search subscriptions by additional fields" and find this error.

Search) The form in the left column of the page keeps the current search values only for non-additional fields. Every time the user selects "Search", the search values currently chosen for the additional searchable fields are lost or ruined.
In case of category additional fields, the current search values are lost, reset to "ALL" every time the user selects "Search".
In case of marc additional fields, the current search values are set to a Hash value every time the user selects "Search".

So I pass the patch to "Failed QA" status.

(In reply to Paola Rossi from comment #97)
> Search) The form in the left column of the page keeps the current search
> values only for non-additional fields. Every time the user selects "Search",
> the search values currently chosen for the additional searchable fields are
> lost or ruined.
> In case of category additional fields, the current search values are lost,
> reset to "ALL" every time the user selects "Search".
> In case of marc additional fields, the current search values are set to a
> Hash value every time the user selects "Search".
> 
> So I pass the patch to "Failed QA" status.

Arg, stupid mistake, sorry.
-                          [% IF av.authorised_value == additional_field_filters.${field.name} %]
+                          [% IF av.authorised_value == additional_field_filters.${field.name}.value %]

This should be fixed now.

I test against master 3.15.00.012

The patch "Update database entry" needs to be rebased.

Applying: Bug 10855: Search subscriptions by additional fields on the claim page
fatal: sha1 information is lacking or useless (C4/Serials.pm).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 10855: Search subscriptions by additional fields on the claim page

So I pass the patch to "Patch doesn't apply" status.

I apply the patch against master 3.15.00.012.

Adding a new subscription, after saving, the marc additional field is not automatically filled with the specified marc field of the notice.
On the contrary, the values of category additional fields appear in new columns of the table.
The values of the marc fields appear only once the subscription has been modified.

I shall not work on bugzilla in the next weeks.

So I pass the patch to "Failed QA" status.

(In reply to Paola Rossi from comment #110)
> I apply the patch against master 3.15.00.012.
> 
> Adding a new subscription, after saving, the marc additional field is not
> automatically filled with the specified marc field of the notice.

Good catch! A previous change did not affect the subscription creation, only modification.
It should work with the last patch.

Before testing again this patch, would it be possible to include 2 observations :
- koha should be able to combine both an authorized value and a marc value  (995 for unimarc or 952 for marc21) for new fields (not only one of them)
- koha should add the following condition: if "create an item record when receiving this serial" is selected in the subscription form, the value of the new subcription fields is duplicated in item record field (952 if marc21 952 or 995 if UNIMARC)

Caution : 10855 et 7677 should be compatible
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7677

(In reply to Koha Team AMU from comment #115)
> Caution : 10855 et 7677 should be compatible
> http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7677

No I disagree, in a first time this feature can be pushed as it.

The sandbox you've requested is not ready.
Some problems occurred applying patches from bug 10855:
<h1>Something went wrong !</h1>Applying: Bug 10855: Add the new package Koha::AdditionalField
Applying: Bug 10855: Add unit tests for the new package Koha::AdditionalField
Applying: Bug 10855: interface configuration for adding new fields to subscriptions
Applying: Bug 10855: New fields on adding/updating a subscription
Applying: Bug 10855: Search subscriptions by additional fields
Applying: Bug 10855: Search subscriptions by additional fields on the claim page
fatal: sha1 information is lacking or useless (C4/Serials.pm).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Bug 10855: Search subscriptions by additional fields on the claim page
When you have resolved this problem run git bz apply --continue.
If you would prefer to skip this patch, instead run git bz apply --skip.
To restore the original branch and stop patching run git bz apply --abort.
Bug 10855 - Additional fields for subscriptions

23594 - Bug 10855: Add the new package Koha::AdditionalField
23595 - Bug 10855: Add unit tests for the new package Koha::AdditionalField
23596 - Bug 10855: interface configuration for adding new fields to subscriptions
23597 - Bug 10855: New fields on adding/updating a subscription
23598 - Bug 10855: Search subscriptions by additional fields
24452 - Bug 10855: Search subscriptions by additional fields on the claim page
24453 - Bug 10855: Squash several fixes
24454 - Bug 10855: Fix QA issues
24455 - Bug 10855: FIX bad conflict merge
24456 - Bug 10855: search with exact match if linked to an AV
24569 - Bug 10855: Update database entry
24570 - Bug 10855: Additional marc fields are not inserted

Apply? [(y)es, (n)o, (i)nteractive] Patch left in /tmp/Bug-10855-Search-subscriptions-by-additional-field-VvngGr.patch .

Tested on sandbox 15 biblibre Unimarc, I had two problems :
- edit or create subscription : 
       - wrong display of diacritics in Additional field with authorised value drop down menu (exemple : indéterminé = pb with é display)
       - can't write in the box of an Additional field with MARC tag

prove -v t/db_dependent/AdditionalField.t gives those errors:

not ok 30 - get_matching_record_ids: field af1: value_for_af1_3 matches subscription1

not ok 31 - get_matching_record_ids: fields af1:value_for_af1_3 and af2:value_for_af2_3 match subscription1

not ok 32 - get_matching_record_ids: field common: common_value matches subscription1

not ok 33 - get_matching_record_ids: field common: common_value matches subscription2 too

Testing on MARC21 the two problems reported in comment 125 are still present.

When I edit or create subscription : 

1)Wrong display of diacritics in Additional field done with authorised value drop down menu (exemple : indéterminé = pb with é display)

2)I can't write in the box of an Additional field connect with MARC tag

With  prove t/db_dependent/AdditionalField.t all test are correct.

(In reply to Zeno Tajoli from comment #135)
> Testing on MARC21 the two problems reported in comment 125 are still present.
> 
> When I edit or create subscription : 
> 
> 1)Wrong display of diacritics in Additional field done with authorised value
> drop down menu (exemple : indéterminé = pb with é display)

Could be fix with bug 11302.

> 2)I can't write in the box of an Additional field connect with MARC tag
> 
> With  prove t/db_dependent/AdditionalField.t all test are correct.

It is the expected behavior. If an additional field is linked to a MARC tag, the value is retrieved from the record, so it is normal you cannot enter something.

(In reply to Jonathan Druart from comment #136)

> > 1)Wrong display of diacritics in Additional field done with authorised value
> > drop down menu (exemple : indéterminé = pb with é display)
> 
> Could be fix with bug 11302.
> 

Unfortunately, current iteration of 11302 patch seems to have some nasty, unexpected side effects in cases when there are uft-8 characters in additional field names (see bug 11302 comment #9).

(In reply to Jonathan Druart from comment #138)

> Bug 10855: FIX encoding issues.

1) still needs ca 100 '| html_entity' to be added in various templates (just kidding, only 10 or so ;)
2) it's not plack compatible ("Variable "$additional_fields" will not stay shared at /home/koha/devkohaclone/serials/subscription-add.pl line 439") - I guess it's just a typo in:

   sub insert_additional_fields {
       my ( $additional_fiels, $biblionumber, $subscriptionid ) = @_;

(In reply to Jacek Ablewicz from comment #139)
> 1) still needs ca 100 '| html_entity' to be added in various templates (just
> kidding, only 10 or so ;)

I would prefer another solution too.

> 2) it's not plack compatible ("Variable "$additional_fields" will not stay
> shared at /home/koha/devkohaclone/serials/subscription-add.pl line 439") - I
> guess it's just a typo in:
> 
>    sub insert_additional_fields {
>        my ( $additional_fiels, $biblionumber, $subscriptionid ) = @_;

Thanks for the catch! Sorry for that.

All patches rebased. Conflicts on serials/claims.tt

I remove the dependency on bug 11944.
The patches have not been developed on top of patches from bug 11944.

I've applied against master 3.17.00.008

On the subscriptions advanced search page
  (serials/serials-search.pl) (in comment 146):

in the table results, at the bottom of all the columns, the various filters "Search ...." were not OK:

If I wrote a value shown only in 1 cell of the column, nothing changed: all the rows were still listed.
If I wrote a value not present in the column, nothing changed: all the rows were still listed.

[On the contrary, on the claims' table results the bottom filters were OK:
If I wrote a value shown only in 1 cell of the column, only 1 row was listed, the other rows disappeared.
If I wrote a value not present in the column, no row were still listed.
So the test plan in comment 147 was OK about column filters of the table results.]

So I pass the patch to "Failed QA" status.

It's a pity that this problem blocks this patch ! This functionnality is usefull !

(In reply to Paola Rossi from comment #157)
> in the table results, at the bottom of all the columns, the various filters
> "Search ...." were not OK:

Fixed with last patch.

I know this patch set doesn't correctly deal with utf8 characters but I cannot manage 1 patch set applied on top of bug 10855 and another one.

So I know this limitation and I will provide follow-ups when these patches will be pushed to master (before or after bug 10855).

(In reply to Jonathan Druart from comment #160)
> (In reply to Paola Rossi from comment #157)
> > in the table results, at the bottom of all the columns, the various filters
> > "Search ...." were not OK:
> 
> Fixed with last patch.
> 

Thanks, Jonathan.
The problem was fixed in the table results of the open subscriptions, 
but not in the table results of the closed ones, same page.

So I've passed again the patch to "Failed QA" status.

NB. In the Update database entry patch (the 10-th), DBversion = "3.15.00.XXX" should be updated.

(In reply to Paola Rossi from comment #161)
> The problem was fixed in the table results of the open subscriptions, 
> but not in the table results of the closed ones, same page.

Arg, sorry. That should be fixed now.

Thanks, Jonathan. Now the problem in comment 161 is OK.

I've applied against master 3.17.00.008

A) In the result table of closed subscriptions, on advanced search, the category additional fields are not shown.

B) In the advanced search, in the result table of open SS, the name "Routing list" is posed on the wrong column, at the left of the column about routing lists.

C) updatedatabase needs to be updated from DBversion 3.15.00.XXX.

So I've passed the patch to "Failed QA" status.

Note-1. If the additional fields are a lot, the table is very large.
Some columns, such as ISSN, don't need so much width.
Perhaps the functions (reopen, new, serial receive, issue history, ...) would be better seen at the left part of the rows.

Note-2 Multiple occurrences of a MARC subfield: The patch filles Additional MARC fields with 1 subfield only
2-1: on repeatable MARC fields:
I've create a subscription about a biblio whose 650 is triple; 650$v is present in all the three occurrences of 650.
I've added an additional MARC field linked to 650$v.
The field of the subscription is only filled with one occurrence of the 3 650$v subfields.

2.2: on repeated subfields in a MARC field:
I've create a subscription about a biblio with one 650 and two 650$x in it.
I've added an additional MARC field linked to 650$x.
The field of the subscription is only filled with the first occurrence of the 2 650$x subfields.

I beg your pardon, and add a further 3-rd note at comment 164.

Note-3: On claims, "Send notification" has sent nothing.
But it has happened on master too.
So I've not been able to test a good regression of the "Send notification".
On the contrary, testing "Download selected claims" has been OK.

Hello Paola,
Thanks for testing and for your patience, but I don't manage to retest this development every time I rebase it.
I would prefer to see bug 11944 pushed before continuing here.
I mark this enh blocked by 11944.

Back to needs signoff for even more fun :)

I've applied the 11 patches against master 3.19.00.006 head 12889

Then:
prove t/db_dependent/AdditionalField.t
t/db_dependent/AdditionalField.t .. 1/37 Undefined subroutine &C4::Bookseller::AddBookseller called at t/db_dependent/AdditionalField.t line 110.
# Looks like you planned 37 tests but ran 20.
# Looks like your test exited with 255 just after 20.
t/db_dependent/AdditionalField.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 17/37 subtests 
 
Test Summary Report
-------------------
t/db_dependent/AdditionalField.t (Wstat: 65280 Tests: 20 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 37 tests but ran 20.
Files=1, Tests=20,  1 wallclock secs ( 0.00 usr  0.02 sys +  0.76 cusr  0.11 csys =  0.89 CPU)
Result: FAIL

So I pass the patch to "Failed QA" status.

I add to my last comment (179):
NB. about the 9-th patch, the updated database has no "COLLATE".

Thanks, Jonathan.

I've applied the 12 patches against master 3.19.00.006 head 12889.

In Comment 168:
>Test plan:
>- prove t/db_dependent/AdditionalField.t

OK!

In Comment 169:
>Test plan:
>- go to serials/serials-home.pl
>- click on the "Add subscription fields" link on the left of the screen
>- try to add/update/delete new fields

I've added a new field with no "Authorised value category" and no MARC field [either searchable or not-searchable].

I think this is an error.

For now I pass the patch to "Failed QA".

(In reply to Paola Rossi from comment #183)
> I've added a new field with no "Authorised value category" and no MARC field
> [either searchable or not-searchable].
> 
> I think this is an error.

No, it is just a free text.

(In reply to Jonathan Druart from comment #184)
> (In reply to Paola Rossi from comment #183)
> > I've added a new field with no "Authorised value category" and no MARC field
> > [either searchable or not-searchable].
> > 
> > I think this is an error.
> 
> No, it is just a free text.

Thanks, Jonathan. So I turn back to "Needs Signed Off".

(In reply to Jonathan Druart from comment #171)
> Created attachment 35215 [details] [review] [review]
> Bug 10855: Search subscriptions by additional fields
> 
> Now you will abble to search subscriptions by additional fields.
> The additional field values will be displayed in the table results.
> 
> Test plan:
> - go on the subscriptions advanced search page
>   (serials/serials-search.pl).
> - verify all searchable additional fields are displayed on the form.
> - combine 1 or more values and verify results are consistent.
> - verify the values are displayed in new columns of the table.
> - for field linked to an authorised value category, the description is
>   displayed (not the code).

I've applied the patches.

Everything was OK as required in the "Open (X)" tag (RIGHT).

In the "Close (X)" tag the MARC additional fields of the subscriptions were displayed (RIGHT) whilst the category additional fields were not displayed (I think it was an ERROR).

I pass the patch to "Failed QA" status.

(In reply to Paola Rossi from comment #186)
> In the "Close (X)" tag the MARC additional fields of the subscriptions were
> displayed (RIGHT) whilst the category additional fields were not displayed
> (I think it was an ERROR).

Good catch!
This is fixed with the last patch.

Thanks, Jonathan.
I've applied the [13] patches against master 3.19.00.006 head 13526 (!).

As required in comment 172 [but I think that this step could also be added 
to the test plan in comment 171]
- try filters on columns.
a particular problem arose on FILTERING. See below.

Moreover, being this patch closely related to authorized values and categories, 
I was in doubt about the displaying of the branch-limited additional values, as 
it is described by 3.18 manual. I've provided a possible "solution". Please 
see all in the NB.1 below.

I think that on FILTERING there can be an error.
For now I pass the patch in the "Failed QA" status.

If FILTERING is not an error, and displaying AV is not a problem, and no other 
follow up is needed, I can sign off this patch attaching the 13 patches as 
usual.

---- FILTERING
RIGHT:
Some subscriptions had "periodicals" in a field of theirs. I've selected all of
 them in some way.
Filtering by "perioa" at once no subscription was expected to be selected.
It happened in 1 second (RIGHT) [subscriptions disappeared]
I cancelled all the filter value: all those subscriptions were expected to be 
selected.
It happened in 1 second (RIGHT) [subscriptions appeared again]
[Now there was no filter value]
Filtering by "perioà" at once [CTRL v] no subscription were expected to selected.
It happened in 1 second (RIGHT).
RIGHT "Incremental" filtering:
Filtering by "perio" at once all those subscriptions were expected to be 
selected.
It happened (RIGHT): nothing changed in the table.
I added "a" at the right of the value, so I was "incrementally" filtering by "perioa".
No subscription were expected to selected.
It happened in 1 second (RIGHT).

ERROR: "Incremental" filtering by adding diacritics exited in ERROR:
Some subscriptions had "periodicals" in a field of theirs. I've selected all of 
them in some way.
Filtering by "perio" all subscriptions were filtered (OK, like above RIGHT).
I added "à" at the right of the value, so I was "incrementally" filtering by "perioà".
No limitation happened in the resulting table in 30 seconds (ERROR).
After 30 sec, I added "ò" at the right of the value, so I was "incrementally" filtering by "perioàò".
No limitation happened in the resulting table in 30 seconds (ERROR).

This error didn't happened adding "incrementally" to "perio":
a Japanese (会) char, 
a number,
a Greek (γ) char.

This error occurred either on searching subscriptions' table or on serials 
claims' one.
---- FILTERING's ERROR END

NB1. A special case of authorized values is about categories with 
branches-limited AV. See:
<http://manual.koha-community.org/3.18/en/basicparams.html#authorizedvalues>
At point 232, [3.18] manual says about their setting:
"If you would like to limit this authorized value category to only specific 
libraries you can choose them from the 'Branches limitation' menu. To have it 
show for all libraries just choose 'All branches' at the top of the list."

This patch's behaviour about the branches-limited AVs was OK (RIGHT).
At my tests, patch is OK [=as plan require] on a category whose AVs are all branch-limited, and 
also on a category whose AVs are a mixture of limited and not-limited.
As desired and required by this patch's test plans:
branches-limited AV are displayed on viewing a subscription, (subscription-detail.pl)
(B) categories names [not the limited AVs' drop down list, like manual says] are shown on editing a subscription (subscription-add.pl)
branches-limited AV are all displayed in the resulting tables,
branches-limited AV are all "filter-able" in the resulting tables,
(A) categories names [not the limited AVs' drop down list, like manual says] are shown among search fields on the left on searching subscriptions.

IMO these branches-limited AV could also be displayed in the (A) drop down list (A), to be available to the selecting user.
Assigning an attribute is not modifying/adding a value to a category. So IMO 
the (B) drop down list could also be shown.
In simple terms the limit in 3.18 manual would be updated from:
"To have it show"
to:
"A branch-limited AV is always shown to all libraries. To have it added and modified"

Otherwise, if the current manual prevales, the part of this patch requiring to  "show" AdVs could need to be reviewed. 
[Or Additional Values are not exactly a kind of Authorized Values.]

Anyway, now this sentence of the manual:
"If you would like to limit this authorized value category to only specific libraries you can choose them from the 'Branches limitation' menu."
appears a little generic to me, not enough to let understand the "limit". 
The sentence could also be changed into:
"If you would like to limit this authorized value to only specific libraries [...]"
because each AuV can be "limited".

NB2. This patch is closely related to authorized values&categories 
[adding/modifying].
http://manual.koha-community.org/3.18/en/basicparams.html#authorizedvalues
point 232: "Limit your Category to 10 characters  (something short to make it clear what the category is for)"

The user of this enhancement 10855 would probably be interested in using more 
than 10 chars. This manual's warning limit might be increased.
------------------------------------------------

(In reply to Paola Rossi from comment #189)

Hello Paola,

Thanks for this complete feedback :)

> ---- FILTERING
> No limitation happened in the resulting table in 30 seconds (ERROR).
> After 30 sec, I added "ò" at the right of the value, so I was
> "incrementally" filtering by "perioàò".
> No limitation happened in the resulting table in 30 seconds (ERROR).

1 sec should be enough, the results are filtered on client-side.
I am sorry but I don't reproduce your problem.
On the serial claims page (but tested also on the serials result page), I have 10 subscriptions, 3 of them have "Psychologies" as a value of an additional field named "testé".
If I enter "Psycho" in the filter, I got the 3 (OK).
If I enter "Psychoé", "Psychoà" or whatever different of "Psychol", the table displays no result.

---- NB1
> (A) categories names [not the limited AVs' drop down list, like manual says]
> are shown among search fields on the left on searching subscriptions.
> 
> IMO these branches-limited AV could also be displayed in the (A) drop down
> list (A), to be available to the selecting user.
> Assigning an attribute is not modifying/adding a value to a category. So IMO 
> the (B) drop down list could also be shown.
> In simple terms the limit in 3.18 manual would be updated from:
> "To have it show"
> to:
> "A branch-limited AV is always shown to all libraries. To have it added and
> modified"

Yes, I see what you meant.
I don't really know what is the behavior to have here, I would prefer to wait for the QA step before submitting a new patch for that.
This point could be relevant.

> NB2. This patch is closely related to authorized values&categories 
> [adding/modifying].
> http://manual.koha-community.org/3.18/en/basicparams.html#authorizedvalues
> point 232: "Limit your Category to 10 characters  (something short to make
> it clear what the category is for)"
> 
> The user of this enhancement 10855 would probably be interested in using
> more 
> than 10 chars. This manual's warning limit might be increased.

The manual is right, for 3.18.
But since bug 13379 (pushed to master), authorised_values.category is a varchar(32).

It would be great if you managed to reproduce the filtering issue on a sandbox (and tell me which one you have used) or took a screenshot before and after you filled the filter with the diacritic character.

Created attachment 35556 [details]
screen-sandbox-8

Thanks, Jonathan.

The "incremental-filtering-of-diacritics" error happens because
rows in the table are shown even if the filtering values are not
present for that row, in spite of disappear.
This error occurs only in the filters at the bottom of the columns,
not at the top "Search" filter (OK).

The error occurs on master too (I used the sandbox 8): see the attached screen.

In the filtering on sandbox, I've added the diacritics in any position of the
string value [i.e. in the middle of the value, at right, aso] one by one, and each diacritic as the last input char for that column.

The error occurs only using this browser :
Firefox [version 35.0.1]

On the contrary these browsers are OK:
IE 11.0
Opera 12.16
Google Chrome 40.0

Being this error present in the master, it's not related to this bug 10855.
So this bug could be signed off in relation of this error.

About the 3 points at comment 190, I think that I can pass this patch to the "Sign off" status.

[I only attach the screen.]

(In reply to Paola Rossi from comment #192)
> Created attachment 35556 [details]
> screen-sandbox-8
> 
> Thanks, Jonathan.
> 
> The "incremental-filtering-of-diacritics" error happens because
> rows in the table are shown even if the filtering values are not
> present for that row, in spite of disappear.
> This error occurs only in the filters at the bottom of the columns,
> not at the top "Search" filter (OK).
> 
> The error occurs on master too (I used the sandbox 8): see the attached
> screen.

Outch, weird. Could you please open a new bug report for this problem?

Jonathan - 

updatabase just needs a quick rebase.  

Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
Auto-merging installer/data/mysql/kohastructure.sql
Failed to merge in the changes.
Patch failed at 0001 Bug 10855: Update database entry

Thanks - Then I can test/qa.

-Brendan

There is a problem here - if you query these new tables and some of the old tables you get an error :


ERROR 1267 (HY000): Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and (utf8_general_ci,IMPLICIT) for operation '='


Here's the query - we should probably fix the collation on the new table and/or the old tables.


select s.subscriptionid, b.title 
from serial s 
left join biblio b using (biblionumber) 
left join additional_field_values d on (d.record_id=s.subscriptionid) 
left join authorised_values v on (d.value=v.authorised_value)

(In reply to Nicole C. Engard from comment #222)

The query works for me, maybe you was using an old patchset?
With the last patches, the correct collation (utf8_unicode_ci) is used for the new tables.

Julian, there is a bug here.
The additional_field_values entries are not deleted when a subscription is deleted.

Created attachment 42297 [details] [review]
Bug 10855: Add the new package Koha::AdditionalField

Rebased on master

Created attachment 42298 [details] [review]
Bug 10855: Add unit tests for the new package Koha::AdditionalField

Rebased on master

Created attachment 42299 [details] [review]
Bug 10855: interface configuration for adding new fields to subscriptions

Rebased on master

Created attachment 42300 [details] [review]
Bug 10855: New fields on adding/updating a subscription

Rebased on master

Created attachment 42301 [details] [review]
Bug 10855: Search subscriptions by additional fields

Rebased on master

Created attachment 42302 [details] [review]
Bug 10855: Search subscriptions by additional fields on the claim page

Rebased on master

Created attachment 42303 [details] [review]
Bug 10855: Squash several fixes

Rebased on master

Created attachment 42304 [details] [review]
Bug 10855: Fix QA issues

Rebased on master

Created attachment 42305 [details] [review]
Bug 10855: search with exact match if linked to an AV

Rebased on master

Created attachment 42306 [details] [review]
Bug 10855: Additional marc fields are not inserted

Rebased on master

Created attachment 42307 [details] [review]
Bug 10855: Make tests to pass

Rebased on master

Created attachment 42308 [details] [review]
Bug 10855: (follow-up) Search subscriptions by additional fields

Rebased on master

Created attachment 42309 [details] [review]
Bug 10855: Update database entry

Rebased on master

Created attachment 42332 [details] [review]
Bug 10855: Remove additional field values when subscription is removed

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Created attachment 42333 [details] [review]
Bug 10855: (follow-up) Bug 10855: Remove additional field values when subscription is removed

The subscriptionid should not be escaped and placeholders used.

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>

Back in the RM queue.

Created attachment 43076 [details] [review]
Bug 10855: (RM followup) DBIx update

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>

Feature pushed to master.

Good job Jonatahn! and thanks Maurice for the followup.

(In reply to Tomás Cohen Arazi from comment #244)
> Feature pushed to master.
> 
> Good job Jonatahn! and thanks Maurice for the followup.

Jonathan and Julian :-D

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