Bug 4173 - Statuses not appearing in the OPAC
Summary: Statuses not appearing in the OPAC
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: 3.8
Hardware: All All
: P3 normal (vote)
Assignee: Owen Leonard
QA Contact: Marcel de Rooy
URL:
Keywords:
: 5677 8093 (view as bug list)
Depends on: 4237 10266
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-12 11:15 UTC by Nicole C. Engard
Modified: 2017-09-11 18:38 UTC (History)
15 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
items in opac (w/out status) (129.37 KB, image/png)
2010-02-12 23:15 UTC, Chris Cormack
Details
items in staff w/ status (136.29 KB, image/png)
2010-02-12 23:15 UTC, Chris Cormack
Details
items in staff w/ status (pt2) (33.75 KB, image/png)
2010-02-12 23:16 UTC, Chris Cormack
Details
Proposed fix (3.73 KB, patch)
2010-04-13 18:55 UTC, Chris Cormack
Details | Diff | Splinter Review
Proposed fix (4.23 KB, patch)
2010-12-06 17:28 UTC, Owen Leonard
Details | Diff | Splinter Review
not for loan in opac (28.43 KB, image/png)
2010-12-16 15:12 UTC, Nicole C. Engard
Details
available in staff (26.07 KB, image/png)
2010-12-16 15:12 UTC, Nicole C. Engard
Details
Bug 4173 - Statuses not appearing in the OPAC (4.47 KB, patch)
2012-07-12 14:49 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 4173 - Statuses not appearing in the OPAC (4.53 KB, patch)
2012-07-25 14:18 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 4173: Followup: put the lib into a variable (1.76 KB, patch)
2012-07-25 14:23 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 4173: Followup: put the lib into a variable (1.81 KB, patch)
2012-07-25 16:13 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 4173: Followup: Document KohaAuthorisedValues plugin (1.43 KB, patch)
2012-09-06 13:23 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 4173: Followup: Document KohaAuthorisedValues plugin (1.43 KB, patch)
2012-09-06 13:39 UTC, Kyle M Hall
Details | Diff | Splinter Review
Proposed fix (1.08 KB, patch)
2013-05-15 14:57 UTC, Rafal Kopaczka
Details | Diff | Splinter Review
Bug 4173 - Statuses not appearing in the OPAC Simply revert order of 2 lines in Items.pm. Previous line write to variable used in next line as function argument. (1.59 KB, patch)
2013-05-15 22:29 UTC, Liz Rea
Details | Diff | Splinter Review
[3.8.x] Bug 4173 - Statuses not appearing in the OPAC Simply revert order of 2 lines in Items.pm. Previous line write to variable used in next line as function argument. (1.60 KB, patch)
2013-05-15 22:57 UTC, Liz Rea
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:24:00 UTC


---- Reported by nengard@gmail.com 2010-02-12 23:15:26 ----

Created an attachment
items in opac (w/out status)

When in the OPAC the authorized values for item statuses are not appearing.  See the attached images.  I set several items to different types and put the type in the public notes field so I could keep track of them all.  These values all came from an authorized value field - in which I entered text in the OPAC display field ... but it's not displaying.

If the authorized values allow for me to enter a value for the OPAC then it should appear in the OPAC.  

Examples included values in:

RESTRICTED
LOST
NOT_LOAN
DAMANGED



---- Additional Comments From nengard@gmail.com 2010-02-12 23:15:47 ----

Created an attachment
items in staff w/ status





---- Additional Comments From nengard@gmail.com 2010-02-12 23:16:06 ----

Created an attachment
items in staff w/ status (pt2)





---- Additional Comments From oleonard@myacpl.org 2010-02-22 21:42:21 ----

1. Lost: this status displays correctly but doesn't display the authorized value description. My guess is that this is by design: What use is it to the patron to know in what sense an item is lost? On the other hand, that's what the "hidelostitems" system preference is for--if patrons don't need to know information about lost stuff, just hide it. So maybe there is a good argument to display the authorized value if a library has chosen to leave "hidelostitems" off.

2. Damaged: Same as Lost, status displays correctly but doesn't display the authorized value description. I could see this argued either way. I think the key is asking what use the information might be to a patron, for instance whether knowing more details tells the patron whether it is worth placing a hold on the item.

3. Not for loan: status displays and shows authorized value correctly.

4. Use Restrictions: Doesn't display at all. This makes sense, as setting a value in "use restrictions" doesn't actually do anything. There is no logic built into Koha to change handling of an item with such a value present.

What should it do?



---- Additional Comments From nengard@gmail.com 2010-02-23 12:12:32 ----

The should all show the authorized values - otherwise why bother having them?  

In particular Use Restrictions - I have an academic library who want the patrons to see any restrictions on use they might apply - and why have a field and an authorized value if nothing it doesn't do anything? :)

Now - if http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4237 goes through then at least the library have a way to communicate item statuses with patrons - but right now I have librarians asking how to actually show the status they want.



---- Additional Comments From oleonard@myacpl.org 2010-02-23 13:24:03 ----

"Why have a field and an authorized value if nothing it doesn't do anything?" Exactly--let's get rid of the authorized value if putting data in it has no effect on functionality.



---- Additional Comments From nengard@gmail.com 2010-02-23 14:07:28 ----

I don't need functionality - I just need it to display - it's a valid field - and it should display any statuses that libraries want to put in there!  :)



---- Additional Comments From oleonard@myacpl.org 2010-04-13 18:55:48 ----

Created an attachment
Proposed fix

Adds output of "RESTRICTED" authorized value (an item's "Use Restriction" status)



---- Additional Comments From gmcharlt@gmail.com 2010-04-16 11:22:53 ----

(In reply to comment #4)
> The should all show the authorized values - otherwise why bother having them? 

For staff display, not OPAC. 




---- Additional Comments From nengard@gmail.com 2010-04-20 12:56:40 ----

Well, I've had a lot of libraries I've trained ask how to get theses to show in the OPAC - so I'm going to say the bad word - maybe we should have a sys pref on whether to show the statuses in staff only or in the staff and OPAC



---- Additional Comments From oleonard@myacpl.org 2010-05-04 15:44:06 ----

(From update of attachment 1806 [details])
Looks like this has been made obsolete by the work for http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4396 which adds a separate template for status handling. Will have to re-work.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:24 UTC  ---

This bug was previously known as _bug_ 4173 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4173
Imported an attachment (id=1884)
Imported an attachment (id=1885)
Imported an attachment (id=1886)
Imported an attachment (id=1887)

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
CC member thehaven104@gmail.com does not have an account here
The original submitter of attachment 1884 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 1885 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 1886 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.
The original submitter of attachment 1887 [details] [review] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Nicole C. Engard 2010-06-02 12:37:18 UTC
the link to the bug that owen references is now: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4396
Comment 2 Owen Leonard 2010-07-20 14:04:17 UTC
How should "Use Restrictions" display? It is informational only, since it isn't connected to any circulation restrictions. That means you can't make it conditional on any other status like "Not for loan." My original idea was to put it in parentheses:

Available (White gloves only)
Not for loan (White gloves only)

...but doesn't make sense here:

Lost (White gloves only)
On hold (White gloves only)

...etc, with checked out, in transit, withdrawn, and damaged.

Perhaps display it only if the status is Available or Not for loan?
Comment 3 Nicole C. Engard 2010-07-20 15:50:07 UTC
I think this is a larger problem ... use restrictions is part of the marc item record and so it's there, but it shouldn't be there if we aren't using it for actually restrictions in cataloging.  I'd say have it display in parens like you have shown and it's up to the library to make the notes make sense with the loan/not for loan status.  

I'd then create a new bug to say that use restrictions should be considered in some sort of way by the circ rules.

Just my 2 cents.
Comment 4 Owen Leonard 2010-12-06 17:28:07 UTC Comment hidden (obsolete)
Comment 5 Chris Cormack 2010-12-12 21:11:20 UTC
Pushed to master please test
Comment 6 Nicole C. Engard 2010-12-16 15:12:04 UTC
Created attachment 2863 [details]
not for loan in opac

When I put a use restriction on an item (and no 'not for loan' status) it says in the opac that it's not for loan and shows the restriction.

However it shows as 'available' in the staff client (see next attachment).

I'm not with either, but it should be consistent on both screens.
Comment 7 Nicole C. Engard 2010-12-16 15:12:29 UTC
Created attachment 2864 [details]
available in staff
Comment 8 MJ Ray (software.coop) 2011-01-06 10:18:11 UTC
This bug is mentioned in:
Fix for Bug 4173 - Statuses not appearing in	the OPAC http://lists.koha-community.org/pipermail/koha-patches/2010-December/013178.html
Fix for Bug 4173 - Statuses not	appearing in the OPAC http://lists.koha-community.org/pipermail/koha-patches/2010-December/013226.html
Comment 9 Owen Leonard 2011-02-01 14:15:05 UTC
*** Bug 5677 has been marked as a duplicate of this bug. ***
Comment 10 Melia Meggs 2012-05-15 18:16:14 UTC
Reopening at Owen's suggestion.

In authorized values, there is a column for Description(OPAC) for Lost, but even when you fill in the OPAC description column, the item still shows in the OPAC simply as "lost" rather than what you write for the description.

I know that for Lost in particular many libraries do not want all of the different 
lost statuses to show up in the OPAC (for example, the patron doesn't care if it's long ovedue (lost) or lost - either way they can't have it).

But some libraries that go to the effort of filling in the Description(OPAC) column would prefer to see the description that they've written.  It seems that if there is an OPAC description column in the authorized value list, then that is what you should see in the OPAC.
Comment 11 Melia Meggs 2012-05-15 18:16:32 UTC
*** Bug 8093 has been marked as a duplicate of this bug. ***
Comment 12 Kyle M Hall 2012-07-12 14:49:35 UTC Comment hidden (obsolete)
Comment 13 Jonathan Druart 2012-07-25 14:18:48 UTC Comment hidden (obsolete)
Comment 14 Jonathan Druart 2012-07-25 14:23:37 UTC Comment hidden (obsolete)
Comment 15 Kyle M Hall 2012-07-25 16:13:58 UTC Comment hidden (obsolete)
Comment 16 Kyle M Hall 2012-07-25 16:14:43 UTC
(In reply to comment #14)
> Created attachment 11133 [details] [review]
> Bug 4173: Followup: put the lib into a variable
> 
> Kyle,
> 
> Could you have a look at this patch please ?
> I think if we put the result into a T::T variable, we do just 1 call to
> GetAuthorisedValueByCode (instead of 2)

A good idea. Every small efficiency helps!
Comment 17 Marcel de Rooy 2012-08-30 12:05:24 UTC
QA Comment:
Code looks good to me. 
Passed QA
Comment 18 Paul Poulain 2012-09-05 08:51:18 UTC
QA comment : I like very much the idea of Koha/Template/Plugin/KohaAuthorisedValues.pm
... BUT it has no doc at all.

Failing QA for this reason, please provide a follow-up with some doc (it will be trivial, I agree, but it's needed)
Comment 19 Kyle M Hall 2012-09-06 13:23:38 UTC Comment hidden (obsolete)
Comment 20 Kyle M Hall 2012-09-06 13:39:49 UTC Comment hidden (obsolete)
Comment 21 Mason James 2012-09-14 10:24:42 UTC
(In reply to comment #18)
> QA comment : I like very much the idea of
> Koha/Template/Plugin/KohaAuthorisedValues.pm
> ... BUT it has no doc at all.
> 
> Failing QA for this reason, please provide a follow-up with some doc (it
> will be trivial, I agree, but it's needed)


Kyle has added the needed POD, passing QA on this...

$ koha-qa.pl -c 3

testing 3 commit(s) (applied to commit 60790d0)
 * 8c7b14c Bug 4173: Followup: Document KohaAuthorisedValues plugin
      Koha/Template/Plugin/KohaAuthorisedValues.pm

 * b43f0b9 Bug 4173: Followup: put the lib into a variable
      koha-tmpl/opac-tmpl/prog/en/includes/item-status.inc

 * 1308299 Bug 4173 - Statuses not appearing in the OPAC
      C4/Koha.pm
      Koha/Template/Plugin/KohaAuthorisedValues.pm
      koha-tmpl/opac-tmpl/prog/en/includes/item-status.inc

* Koha/Template/Plugin/KohaAuthorisedValues.pm                             OK
* C4/Koha.pm                                                               OK
* koha-tmpl/opac-tmpl/prog/en/includes/item-status.inc                     OK
Comment 22 Paul Poulain 2012-09-14 14:51:54 UTC
Patch pushed to master
Comment 23 Chris Cormack 2012-09-16 08:37:16 UTC
String changes, held until after the string freeze
Comment 24 Chris Cormack 2012-09-25 01:23:07 UTC
Pushed to 3.8.x will be in 3.8.6
Comment 25 Liz Rea 2013-04-04 21:29:34 UTC
It looks like restricted statuses are still not shown. 

I actually have a use case for them now - 

A library wants to show that an item is "ask a librarian" - it's not lost, it's not "not for loan," they just want to indicate that it is restricted access, and they use the restricted authorised value to show that. People also use it to denote "on order" in combination with Not for loan. 

Anyway, I think we have someone willing to sponsor a fix for the restricted status display - so will file a new bug if that comes to pass.
Comment 26 Rafal Kopaczka 2013-05-15 14:57:58 UTC Comment hidden (obsolete)
Comment 27 Fridolin SOMERS 2013-05-15 17:12:38 UTC
(In reply to comment #26)
> Created attachment 18158 [details] [review] [review]
I think this is a new bug.
And it should use KohaAuthorisedValues template plugin on restricted data.
Comment 28 Katrin Fischer 2013-05-15 21:20:30 UTC
Hi Rafal,

thank you for your patch! We are always very happy about new developers.

Let me try to help you to get this into Koha :)

This bug has the status "pushed to stable" which means it's basically done and resolved. If it has a 'Pushed...' status it's always better to file a new bug.

The new bug should have a good description and ideally a test plan that shows people how to reproduce the problem you are trying to fix. The version should be set to master, if it's not a problem that's specific to an older version. Make sure you assign (Assiged to:) the bug to yourself and that you switch the bug status to 'Needs Signoff', which means it's waiting for someone to test.

You can find some information about a bug's life cycle and the different status here: http://wiki.koha-community.org/wiki/Bug-enhancement-patch_Workflow

If you have questions, or need some pointers, or just want to get to know us, I would recommend jumping into the IRC channel. There is almost always someone around willing to help.
Comment 29 Liz Rea 2013-05-15 21:31:57 UTC
It does say patch pushed, but I have observed this still not working correctly - so I'm going to test this patch anyway, and will upload one with the requirements as an example if it fixes the issue.

Liz
Comment 30 Liz Rea 2013-05-15 22:29:30 UTC Comment hidden (obsolete)
Comment 31 Liz Rea 2013-05-15 22:56:35 UTC
This last patch is going to be for 3.8 only, as 3.10+ have the plugin.
Comment 32 Liz Rea 2013-05-15 22:57:47 UTC Comment hidden (obsolete)
Comment 33 Katrin Fischer 2013-05-16 06:02:29 UTC
Hi Liz, I think it's still better to open a new bug when a new problem arises and link it to the old one. If Rafal doesn't beat me to it, I will do it later when doing QA.

My reasoning is that this has been pushed to a long released version of Koha and it takes a lot of time to process bugs like this when you are testing because there are so many comments and other things to look for. Also we have many different people working on this, a new bug is really cleaner.

If the same patch works on master I would say we should use it for now. It looks like an easy fix to a longer existing problem and we shouldn't force people to rewrite lots of code in that case.
Comment 34 Katrin Fischer 2013-05-17 06:03:13 UTC
I have opened bug 10266 for the new patch and passed QA on the patch there. :)