Lineitems by Bib only supports filtering a single state

[Kyle Huckins]

API Call for openils.acq.lineitems_related_by_bib that specify multiple Lineitem States under the lineitem_state filter option does not work, however supplying a single state string does work. Interestingly, the po_state filter does work.

In Open-ILS/src/perlmods/lib/OpenILS/Application/Acq/Lineitem.pm:

if ($options && defined $options->{lineitem_state}) {
    $query->{'where'}{'jub'}{'state'} = $options->{lineitem_state};
}

if ($options && defined $options->{po_state}) {
    $query->{'where'}{'+acqpo'}{'state'} = $options->{po_state};
}

In the code for open-ils.acq.lineitem.search.by_attributes, the following code appears to work:

if ($li_states and @$li_states) {
    $where->{"+jub"} = {"state" => $li_states};
    $searched_for_something = 1;
}

Changing {'jub'} to {'+jub'} in the lineitems_related_by_bib should solve this issue.

[Kyle Huckins (khuckins)]

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/khuckins/lp1744762-lineitem-state-filtering-api

Here's a quick branch that solves the issue. Best way to test this would be to create three active lineitems for a bib record, cancel one, and mark the second as received. Then make an API call with ['on-order', 'received'] passed in for lineitem_state in our options object. It should retrieve the lineitems that weren't canceled.

[Bill Erickson (berick)]

Added a 3.1 target, since this bug does not affect EG proper, because no existing code uses this filter.

[Mike Rylander (mrylander)]

Kyle, that missing "+" is just wrong, but it looks like it should work, if only incidentally, because "jub" is the core class of the query. I'm actually surprised that the in-list version doesn't work, but perhaps there is some subtle difference in the implicit-equals and the implicit-in-list code that's allowing the former to work in what amounts to an extra (useless) "AND" nesting but not the latter.

Bill, the lineitems_related_by_bib sub has been there since 2010 according to git-blame. You don't think the fix should be backported? It looks like a simple typo to me, in any case, right?.

[Terran McCanna (tmccanna)]

I assume from Mike's last comment that this one needs additional work? Removing pullrequest tag for the time being.

[Kyle Huckins (khuckins)]

Only just noticed your reply on this, Terran. I took Mike's statement as confirmation about the issue being a typo, which the patch resolved, but I could be wrong on that. Throwing on the Catalyte test server to get eyes on it

[Tiffany Little (tslittle)]

Kyle, I'm not sure how to test this through the UI. In the new Angular line item search, the only operator options for Line Item-Status search are: is, is not, exists, does not exist, matches a term from a file. And the status options are a predefined list. Trying to select one term, and then manually add a ", [new term]" doesn't work. The search retrieves everything and ignores the search term(s).

[Kyle Huckins (khuckins)]

Hey Tiffany,

Some quick steps from a look at the Angular Acq search UI:

1. Set "Search for records matching x of the following terms" to "Any"
2. Set the initial search term to Line Item - Status, is, On-Order
3. Add an additional search row, set to Line Item - Status, is, Received

It's possible the Angular UI bypasses the issue, however, as I'm not running into the issue with the new search

[Jennifer Pringle (jpringle-u)]

Tested on the new search in 3.7beta and I can confirm that this is no longer an issue. I can retrieve items on-order and received in the same search.

[Tiffany Little (tslittle)]

Based on Kyle and Jennifer's testing, marking this one as Won't Fix. Thanks to you both!