I don't know if it's worth mentioning, but I thought I'd add the following note about indexes:

While itemtype is an index filled by the 952 and the 942, ccode is just filled by the 952. 

--

Fridolyn: Do you have any use cases for when a person would want to limit a "Search for Biblio" when creating a new subscription? 

I imagine it must be there for a reason, but it seems a bit strange to me to use mainly item-based indexes when searching explicitly for a bib record.

(In reply to David Cook from comment #8)
> Fridolyn: Do you have any use cases for when a person would want to limit a
> "Search for Biblio" when creating a new subscription? 
> 
> I imagine it must be there for a reason, but it seems a bit strange to me to
> use mainly item-based indexes when searching explicitly for a bib record.

Yes, one of our libraries asked for this correction.
In UNIMARC configurations, some use itemtype on items to define the way they can circulate (loan 7 days, ...) and use CCODE on biblio to define the physical type of document (Book, DVD, ...).
Some catalogs have for the same title several records with different physical type. That is why they want to filter when creating a subscription, specially if there is a type for serials.

Hm, this has come up on other bugs recently. I am not sure how we should deal with it. For me changing the frameworks to use CCODE on biblevel looks like a customization and I am not sure if we should hardcode that in. It will only be useful under very certain circumstances for specific libraries.

(In reply to Katrin Fischer from comment #10)
How may we correct the bug ?
Show only item type filter, only if defined on biblio level ?

In the end, librarians can perform filtering into the search query : "histoire and itype:perio".

Hi Fridolyn, while I think it won't work for our libraries, it's an existing feature and I will pass it - I just didn't get to finish it last night, because git bz is a bit broken right now, until it gets updated for the new bugzilla version.

Created attachment 22479 [details] [review]
[PASSED QA] Bug 11091 - limits in catalog search when creating subscription

When creating a new subscription, you can click on "Search for Bilbio" to search into catalog.
A popup opens with a text field for search terms and a combo-box to limit search.
This combo-box uses the syspref AdvancedSearchTypes to know what list of values display.
The bug is that the code acts has if AdvancedSearchTypes has always one value, but since Bug 7031, this syspref can have several values (item types, collection codes and locations).

This patch removes the use of AdvancedSearchTypes syspref and defines search form with 2 limits : item types and collection codes (from authorised values CCODE).
One or both of this information can be on biblio. Searching by location seems to be useless because this information is always on item.
If CCODE authorised value does not exist or is empty, the collection code filter is not displayed.

Test plan :
- Check CCODE authorised value exists with some values
- Choose a biblio indexed with both itemtype and ccode indexes
- Go to Serials module and click on "New subscription"
- In form, click on "Search for Biblio"
=> The popup "serials/subscription-bib-search.pl" appears with two limits
- Enter a word of biblio title, select its item type and select its collection code
- Click on "Search"
=> You get the biblio

Signed-off-by: David Noe <drnoe@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
While I am not sure how useful the collection code is for most libraries, where this
is an item level value, this fixes a broken feature and works as described.
Passes all tests and QA script.

Created attachment 22480 [details] [review]
[PASSED QA] Bug 11091 - perltidy on serials/subscription-bib-search.pl

Signed-off-by: David Noe <drnoe@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>

(In reply to Katrin Fischer from comment #12)
> Hi Fridolyn, while I think it won't work for our libraries, it's an existing feature and I will pass it
Ok, thanks a lot.

I agree with Katrin's statements that the way that this patch implements limits assumes things that are simply not true for default MARC21 installations of Koha, where the item type and collection code simply are not biblio-level attributes.  However, this is an improvement over the status quo, so I've pushed this to master.  Thanks, Fridolin!

Those patches has been pushed to 3.14.x, will be in 3.14.1