Bug 11169

Summary: OPAC: Display acquisition details
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: AcquisitionsAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: chris, dcook, gmcharlt, iming, jean-manuel.broust, katrin.fischer, koha, m.de.rooy, mathsabypro, nengard, paola.rossi, pasi.kallinen, sandboxes, tomascohen, veron
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 5336    
Bug Blocks: 11847    
Attachments: Bug 11169: Display acquition details at the OPAC
Bug 11169: [Bootstrap] Display acquition details at the OPAC
MT12445: Hide the date_due column
Bug 11169: Hide the date_due column
Bug 11169: Display acquition details at the OPAC
Bug 11169: [Bootstrap] Display acquition details at the OPAC
Bug 11169: Hide the date_due column
Bug 11169: Display acquition details at the OPAC
Bug 11169: [Bootstrap] Display acquition details at the OPAC
Bug 11169: Hide the date_due column
Bug 11169: Display acquition details at the OPAC
Bug 11169: [Bootstrap] Display acquition details at the OPAC
Bug 11169: Hide the date_due column
Bug 11169: Display acquition details at the OPAC
Bug 11169: [Bootstrap] Display acquition details at the OPAC
Bug 11169: Hide the date_due column
Bug 11169: Display acquition details at the OPAC
Bug 11169: Display acquition details at the OPAC
Bug 11169: Display acquition details at the OPAC
Bug 11169: Fix branch name
Bug 11169: Display acquition details at the OPAC
Bug 11169: Display acquisition details in the OPAC
Bug 11169: (follow-up) add more unit tests
Bug 11169: (follow-up) only count orders that have been placed
no acq note

Description Jonathan Druart 2013-10-30 14:08:17 UTC

    
Comment 1 Jonathan Druart 2013-10-30 14:31:07 UTC Comment hidden (obsolete)
Comment 2 Jonathan Druart 2013-10-30 14:31:26 UTC Comment hidden (obsolete)
Comment 3 Jonathan Druart 2014-02-26 15:23:28 UTC Comment hidden (obsolete)
Comment 4 Jonathan Druart 2014-02-26 15:40:02 UTC Comment hidden (obsolete)
Comment 5 Koha Team University Lyon 3 2014-03-11 11:08:38 UTC
he sandbox you've requested is not ready.
Some problems occurred applying patches from bug 11169:
<h1>Something went wrong !</h1>Applying: Bug 11169: Display acquition details at the OPAC
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging C4/Acquisition.pm
Auto-merging installer/data/mysql/sysprefs.sql
Auto-merging installer/data/mysql/updatedatabase.pl
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/opac.pref
Auto-merging koha-tmpl/opac-tmpl/prog/en/includes/item-status.inc
Auto-merging koha-tmpl/opac-tmpl/prog/en/modules/opac-detail.tt
Auto-merging opac/opac-detail.pl
CONFLICT (content): Merge conflict in opac/opac-detail.pl
Failed to merge in the changes.
Patch failed at 0001 Bug 11169: Display acquition details at the OPAC
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 11169 - OPAC: Display an acquisition details tab

22594 - Bug 11169: Display acquition details at the OPAC
22595 - Bug 11169: [Bootstrap] Display acquition details at the OPAC
25657 - Bug 11169: Hide the date_due column

Apply? [(y)es, (n)o, (i)nteractive] Patch left in /tmp/Bug-11169-Display-acquition-details-at-the-OPAC-CZbyQZ.patch .
Comment 6 Jonathan Druart 2014-03-11 11:17:41 UTC Comment hidden (obsolete)
Comment 7 Jonathan Druart 2014-03-11 11:17:46 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2014-03-11 11:17:51 UTC Comment hidden (obsolete)
Comment 9 Koha Team University Lyon 3 2014-03-11 14:13:59 UTC
Tests made with :
- AcqCreateItems pref to 'receiving'
ok, we can retrieve the title in OPAC with a tab "acquitision details" indicating the number of items in the order. (just a comment : when there's only one item, we can see "1 items are on order" : can you put it singular ?)
it's the same whatever the basket is open, closed, in a basketgroup or not.
If there's a partial receipt, the number of order decrease of the right number.
When all items have been received, the tab disappears. 
After a transfer of command it's also ok.
When you cancel a receipt, the tab reappears with the right number to be received.(But It's a pity that the items stay the items stays in tab "Holdings".)

- AcqCreateItems pref to 'ordering'
ok, we can retrieve the title in OPAC with a tab "acquitision details", with a table of the items in order. it's the same whatever the basket is open, closed, in a basketgroup or not.
If there's a partial receipt, only the item in order stay in the table.
When all items have been received, the tab disappears. 
After a transfer of command it's also ok.
When you cancel a receipt, the tab reappears with the good number to be received.

But, there's something I don't see in the master, so I wonder that's introduced by this patch : if you do a partial receipt, You can't cancel the first items you received. You can only cancel the last one.
I changed in "failed QA" for this.
Comment 10 Jonathan Druart 2014-03-13 12:43:09 UTC
(In reply to Koha Team Lyon 3 from comment #9)
> But, there's something I don't see in the master, so I wonder that's
> introduced by this patch : if you do a partial receipt, You can't cancel the
> first items you received. You can only cancel the last one.
> I changed in "failed QA" for this.

It is not introduced by this patch. It looks the same issue that bug 11744.
Comment 11 jmbroust 2014-03-14 09:25:07 UTC
<h1>Something went wrong !</h1>Applying: Bug 11169: Display acquition details
at the OPAC
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging C4/Acquisition.pm
CONFLICT (content): Merge conflict in C4/Acquisition.pm
Auto-merging installer/data/mysql/sysprefs.sql
Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
Failed to merge in the changes.
Patch failed at 0001 Bug 11169: Display acquition details at the OPAC
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 11169 - OPAC: Display an acquisition details tab

26082 - Bug 11169: Display acquition details at the OPAC
26083 - Bug 11169: [Bootstrap] Display acquition details at the OPAC
26084 - Bug 11169: Hide the date_due column
Comment 12 Jonathan Druart 2014-03-14 09:32:06 UTC Comment hidden (obsolete)
Comment 13 Jonathan Druart 2014-03-14 09:32:11 UTC Comment hidden (obsolete)
Comment 14 Jonathan Druart 2014-03-14 09:32:16 UTC Comment hidden (obsolete)
Comment 15 Biblibre Sandboxes 2014-03-14 11:37:09 UTC
Patch tested with a sandbox, by Broust <jean-manuel.broust@univ-lyon2.fr>
Comment 16 Biblibre Sandboxes 2014-03-14 11:37:48 UTC Comment hidden (obsolete)
Comment 17 Biblibre Sandboxes 2014-03-14 11:37:52 UTC Comment hidden (obsolete)
Comment 18 Biblibre Sandboxes 2014-03-14 11:37:57 UTC Comment hidden (obsolete)
Comment 19 Katrin Fischer 2014-04-06 14:08:07 UTC
*** Bug 11984 has been marked as a duplicate of this bug. ***
Comment 20 Kyle M Hall 2014-04-11 13:28:08 UTC Comment hidden (obsolete)
Comment 21 Kyle M Hall 2014-04-11 13:28:23 UTC Comment hidden (obsolete)
Comment 22 Kyle M Hall 2014-04-11 13:28:57 UTC Comment hidden (obsolete)
Comment 23 Galen Charlton 2014-04-19 17:57:05 UTC
Is a separate tab really necessary?

If the goal is to give patron information that new items are coming, I think it sufficient to:

- display an on-order status in the OPAC holdings tab if items are creating during ordering
- display a statement saying "X items are on order" (or "X items are on order as of $date" to take bug 11847 into account).

Setting to in discussion
Comment 24 Iming Chan 2014-04-21 11:55:57 UTC
Hi Galen,

I don't believe a separate tab is really necessary.  It should be provided like "holds" (reservations).

I like your idea just to give acquisition information in the OPAC holdings tab ** AND ** display a date when X item(s) is/are on order.
Comment 25 David Cook 2014-04-24 04:35:12 UTC
(In reply to Galen Charlton from comment #23)
> Is a separate tab really necessary?
> 
> If the goal is to give patron information that new items are coming, I think
> it sufficient to:
> 
> - display an on-order status in the OPAC holdings tab if items are creating
> during ordering
> - display a statement saying "X items are on order" (or "X items are on
> order as of $date" to take bug 11847 into account).
> 
> Setting to in discussion

Agreed. I think that this or something similar would be all that is necessary.

Furthermore, I don't really like the idea of having an "acquisitions details" tab as it doesn't seem very user centred in design. As a library patron, I might not understand or want to understand anything related to "acquisitions". I just want to know if an item is on order, and when it's going to arrive/when the order was placed.
Comment 26 Katrin Fischer 2014-04-30 06:34:07 UTC
*** Bug 9441 has been marked as a duplicate of this bug. ***
Comment 27 Jonathan Druart 2014-05-08 09:31:54 UTC Comment hidden (obsolete)
Comment 28 Jonathan Druart 2014-05-08 09:33:54 UTC
I rewrote this patch.
I removed the new tab and added the information about items on ordered into the Holdings tab.
Note that I dropped the support for the prog theme.

Back to Needs Signoff.
Comment 29 Paola Rossi 2014-05-21 16:21:59 UTC
I test against 3.15.00.052

When I go to the opac, and I select the opac detail page of a biblio, the system answers:

Software error:
Undefined subroutine &C4::Acquisition::SearchOrders called at /var/root-koha/bug-11169/opac/opac-detail.pl line 603.

So I pass the patch to "Failed QA" status.
Comment 30 Jonathan Druart 2014-05-22 07:44:56 UTC Comment hidden (obsolete)
Comment 31 Paola Rossi 2014-05-22 15:37:12 UTC
I apply the patch against master 3.15.00.052
---------------------------------------------------------------
1) About the preference "AcqCreateItem" set to 'receiving an order', the manual 3.16 says: If you choose to add the item when 'receiving an order' you will be asked for item record information when you're receiving orders in acquisitions.

At step 3 the plan requires:
create some orders on 1 or more items

So, if I add x (1 or more) items to the biblio, before creating the order for the biblio, the step 4 is OK: on OPAC opac-details, I see:
Holdings (x)
[table of items]
x items are on order.

But, if the plan at step 3 means (according the manual):
create some orders _of_ 1 or more items [for a biblio without items]

the step 4 is not OK: on OPAC opac-details, I see this tab for the biblio:
Holdings (0)
No physical items for this record 

and no "X item are on order".
--------------------------------------------------------------
2) At step 9, preference "AcqCreateItem" set to 'placing an order':
for an order of x items, the item list contains 2x items: x items in "Available" status, and x items in "on order" status.
After receiving (step 11), the items in "on order" status disappear.
--------------------------------------------------------------
I beg your pardon if I'm wrong.
I pass the patch to "Failed QA" status.
Comment 32 Paola Rossi 2014-05-23 15:29:22 UTC
Against the master 3.17.00.001 the patch needs to be rebased:

Applying: Bug 11169: Display acquition details at the OPAC
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging installer/data/mysql/updatedatabase.pl
CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
Auto-merging installer/data/mysql/sysprefs.sql
Failed to merge in the changes.
Patch failed at 0001 Bug 11169: Display acquition details at the OPAC

So I pass the patch from "Failed QA" status (please see comment n.31) to "Patch doesn't apply" status.
Comment 33 Jonathan Druart 2014-05-27 11:51:15 UTC Comment hidden (obsolete)
Comment 34 Jonathan Druart 2014-05-27 11:52:21 UTC
(In reply to Paola Rossi from comment #31)
> I beg your pardon if I'm wrong.
> I pass the patch to "Failed QA" status.

No, you were right. That was completely buggy!
Good catch. The last patch should solve these issues.
Comment 35 Paola Rossi 2014-05-27 16:44:35 UTC
Thanks, Jonathan.

I apply against master 3.17.00.007 

Everything's OK, except for regression of OpacSeparateHoldingsBranch.

On master, "Separate"-ing on "Home library" selects and lists in the first tab the items whose home (alias permanent) library is the user's login (i.e. patron's) library.
On the contrary, if I'm not wrong, the patch selects and lists in the first tab the items whose current library is the patron's library.

NB. On OPAC, the items' "permanent library" is not shown: the column is the "Current location", I mean the current library. So the items' permanent library is not able to be seen on OPAC.

I hope to be right, otherwise I beg your pardon.
I pass the patch the "Failed QA" status.
Comment 36 Jonathan Druart 2014-05-28 08:05:33 UTC Comment hidden (obsolete)
Comment 37 Jonathan Druart 2014-05-28 08:07:04 UTC
(In reply to Paola Rossi from comment #35)
Paola, I am not sure to understand the problem. I provided a patch, but I am not sure it will fix what you described.
If not, could you please detail step by step how to reproduce it?
Comment 38 Paola Rossi 2014-05-28 10:43:53 UTC
Thanks, Jonathan. I beg your pardon, yesterday I didn't realize that on OPAC the "MARC view" shows all locations of an item. So I became confused about the matches I annotate below.

NB. The option "home library" of pref "OpacSeparateHoldingsBranch" corresponds to "a-Permanent location" content of an item (additem.pl intranet). And the other option "holding library" corresponds to the following "b-Current location" content of an item.
In advanced search, at tab "Holdings" of a biblio on catalogue/details.pl, the columns show mixed names.
---------------------------------------------
Today I apply against master 3.17.00.007 

I check again the only first patch about the regression.

Everything's OK.

So I pass the first patch "Display acquisition details at tha OPAC" to the "Signed Off" status. 
The second patch "Fix branch name" is not needed.
Comment 39 Paola Rossi 2014-05-28 10:45:09 UTC Comment hidden (obsolete)
Comment 40 Galen Charlton 2014-05-28 18:32:13 UTC
Created attachment 28522 [details] [review]
Bug 11169: Display acquisition details in the OPAC

This patch adds a new system preference 'OPACAcquisitionDetail'.
If it is enabled, information about items on order will be displayed on
the OPAC detail page.

Test plan:
- switch on the OPACAcquisitionDetails pref.
- set the AcqCreateItems pref to 'receiving'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the "Holdings" tab contains the
  line "X item are on order." (at the bottom of the table containing the
  item list).
- receive the items.
- verify the number of items has decreased.
- set the AcqCreateItems pref to 'ordering'.
- create some orders on 1 or more items.
- go to the opac detail page and verify the item list contains the items
  with the "on order" status.
- receive the items.
- verify the received items no longer have the the "on order" status.

To test completely this feature, you should verify there is no
regression on the pref OpacMaxItemsToDisplay, OpacSeparateHoldings and
OpacSeparateHoldingsBranch.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>

Also removed some blank lines from the original patch and bumped up
the DBRev.
Comment 41 Galen Charlton 2014-05-28 18:32:46 UTC
Created attachment 28523 [details] [review]
Bug 11169: (follow-up) add more unit tests

This patch adds direct unit tests of the new biblionumber filter
for SearchOrders.  It also moves the ordernumber filter test
to the rest of the SearchOrders tests.

To test:

[1] Verify that prove -v t/db_dependent/Acquisition.t passes.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Comment 42 Galen Charlton 2014-05-28 18:32:56 UTC
Created attachment 28524 [details] [review]
Bug 11169: (follow-up) only count orders that have been placed

This patch ensures that only orders that have been placed (i.e.,
orders whose basket is closed) are counted in the OPACAcquisitionsDetails
display.

To test:

[1] Turn on OPACAcquisitionsDetails and set AcqCreateItem to 'ordering'.
[2] Create an order for a record, but do not close the basket.
[3] View the record in the OPAC.  It should not display any order count.
[4] Close the bakset.
[5] View the record in the OPAC again.  This time, it should display
    the count of items on order.

Signed-off-by: Galen Charlton <gmc@esilibrary.com>
Comment 43 Chris Cormack 2014-06-08 09:02:40 UTC
Pushed to MM-OPAC/bug_11169

Please merge at your leisure
Comment 44 Tomás Cohen Arazi 2014-06-15 14:16:08 UTC
Patches pushed to master.

Thanks Jonathan and Galen!
Comment 45 paxed 2014-06-23 08:52:38 UTC
From i18n viewpoint, hard-coded plural forms are not good:

    [% IF acquisition_details.total_quantity == 1 %]
      1 item is on order.
    [% ELSE %]
      [% acquisition_details.total_quantity %] items are on order.
    [% END %]

See also:
http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-forms.html
Comment 46 Nicole C. Engard 2014-10-29 14:04:58 UTC
I am writing this up for the manual but can't seem to make it work.  I have the preference set to 'display' but on the titles that have items on order I do no see the acquisitions tab.  Will it only work for items ordered after you turn the preference on? Does it depend on another preference?
Comment 47 Jonathan Druart 2014-11-05 14:59:07 UTC
(In reply to Nicole C. Engard from comment #46)
> I am writing this up for the manual but can't seem to make it work.  I have
> the preference set to 'display' but on the titles that have items on order I
> do no see the acquisitions tab.  Will it only work for items ordered after
> you turn the preference on? Does it depend on another preference?

Hi Nicole,
Sorry for the delay!
Actually in the pushed version, there is no tab!
You must have AcqCreateItem != "ordering" to see the information "X items are on order".
Comment 48 Nicole C. Engard 2014-11-13 15:11:31 UTC
(In reply to Jonathan Druart from comment #47)
> Hi Nicole,
> Sorry for the delay!
> Actually in the pushed version, there is no tab!
> You must have AcqCreateItem != "ordering" to see the information "X items
> are on order".

Oh! Okay. That makes sense.
Comment 49 Nicole C. Engard 2014-11-13 15:15:49 UTC
Created attachment 33522 [details]
no acq note

Hmm, I still don't see it. I set  OPACAcquisitionDetails =display and  AcqCreateItem = cataloging the item and I placed a new order and the opac looks like the attached image. I don't see the note.
Comment 50 Paola Rossi 2014-11-14 15:01:09 UTC
I've created the case of comment 49 against master 3.17.00.054. I hope the following steps be the right ones, and all needed.

1 - I set the syspref "OPACAcquisitionDetails" to "Display"
2 - I set the syspref "AcqCreateItem"  to "cataloguing the record" as required
3 - I created a new vendor, with a basket.
4 - I ordered a book from an external source, setting the quantity to X
5 - I closed the basket [either with or without closing also the basketgroup]
6 - [I reindexed zebra to find the book on OPAC]

On OPAC I saw "X items are on order. " below the "Holdings ( 0 )" tag of the book.

Then I also repeated 1,2,3,5 changing the 4-th step with this one:
4B - I catalogued another book without items, [I reindexed zebra], and I ordered this book "From an existing record", setting the quantity to Y.

Again, on OPAC I saw "Y items are on order. " below the "Holdings ( 0 )" tag of the second book.

NB. if I reopened the basket, or if I didn't close it, on OPAC I saw "No physical items for this record".