The Bug 3333 corrects in Opac by setting notforloan=1. But it has a side effect on intranet search result page due to the use of authorized value on 'notforloan'.
(In reply to Christophe Croullebois from comment #0) > The Bug 3333 corrects in Opac by setting notforloan=1. > But it has a side effect on intranet search result page due to the use of > authorized value on 'notforloan'. What is the exact side effect ?
(In reply to Marcel de Rooy from comment #1) > (In reply to Christophe Croullebois from comment #0) > > The Bug 3333 corrects in Opac by setting notforloan=1. > > But it has a side effect on intranet search result page due to the use of > > authorized value on 'notforloan'. > > What is the exact side effect ? Hello Marcel, one of our customer has authorised values with state values, 'withdrawn', 'repair'... For the 1 value they have 'treatment'. and in items.notforloan the value is 0 in AV it is 'available'. Due to the overwriting of the patch with 1 value, in the page search.pl inside the Location column we see the item with the treatment status instead of the available status.
(In reply to Christophe Croullebois from comment #2) > (In reply to Marcel de Rooy from comment #1) > > (In reply to Christophe Croullebois from comment #0) > > > The Bug 3333 corrects in Opac by setting notforloan=1. > > > But it has a side effect on intranet search result page due to the use of > > > authorized value on 'notforloan'. > > > > What is the exact side effect ? > > Hello Marcel, > > one of our customer has authorised values with state values, 'withdrawn', > 'repair'... > For the 1 value they have 'treatment'. > and in items.notforloan the value is 0 in AV it is 'available'. > Due to the overwriting of the patch with 1 value, in the page search.pl > inside the Location column we see the item with the treatment status instead > of the available status. Christophe, The value is only overwritten if the corresponding item type is set to not for loan. Could you check the item types ? Marcel
I am failing to replicate this - given it's age, I think if it wasn't a configuration issue, it might have been fixed in a different way by now. Please reopen with a test plan if this is still an issue!
Actually, I figured it out: - Change the description of NOT_LOAN = 1 to something easy to recognize - Set an itemtype to "not for loan" - Search for records with items of that item type in staff - Look at the search results - The items will be listed as unavailable, which I think is ok, BUT: each item will show the value of the not for loan = 1, which is not correct I think if the itemtype is marked as not for loan, we should leave it as showing them as unavailable, without looking up a wrong authorised value.
Created attachment 83861 [details] Screenshot of result list with nfl = 1 = Treatment, itemtype books = nfl
I do not recreate: 1. Setting NOT_LOAN=1 to "XXXXXXXXXXXXX" MariaDB [koha_kohadev]> select * from authorised_values where category="NOT_LOAN"; +----+----------+------------------+------------------+----------+----------+ | id | category | authorised_value | lib | lib_opac | imageurl | +----+----------+------------------+------------------+----------+----------+ | 32 | NOT_LOAN | -1 | Ordered | NULL | NULL | | 33 | NOT_LOAN | 1 | XXXXXXXXXXXXX | NULL | | | 34 | NOT_LOAN | 2 | Staff Collection | NULL | NULL | +----+----------+------------------+------------------+----------+----------+ 3 rows in set (0.00 sec) 2. Setting Computer file as not for loan MariaDB [koha_kohadev]> select notforloan from itemtypes where itemtype="CF"; +------------+ | notforloan | +------------+ | 1 | +------------+ 3. Set this itemtype for a given item: MariaDB [koha_kohadev]> select itype from items where biblionumber=4; +-------+ | itype | +-------+ | CF | | BK | | BK | | BK | +-------+ I see: https://snag.gy/YojeUb.jpg
Taking this very urgent bug O:)