Patch tested with a sandbox, by Cédric Vita <cedric.vita@dracenie.com>

Applying: Bug 10858 [Follow-up] Browse selected biblios
Using index info to reconstruct a base tree...
M	koha-tmpl/opac-tmpl/prog/en/css/opac.css
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/opac-tmpl/prog/en/css/opac.css
CONFLICT (content): Merge conflict in koha-tmpl/opac-tmpl/prog/en/css/opac.css
Patch failed at 0001 Bug 10858 [Follow-up] Browse selected biblios
The copy of the patch that failed is found in:
   /home/christopher/git/koha/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Patch tested with a sandbox, by Koha Team Amu <koha.aixmarseille@gmail.com>

Potential development : to have a list of results after the click on the "Browse selected biblios"

Looks good for prog and ccsr opac themes. However, the feature needs to be updated to work with the new bootstrap theme as well.

(In reply to Kyle M Hall from comment #12)

I will open a new report for the bootstrap theme.

Back to Signed off

General question about this proposed feature: what's wrong with using the cart for this?

(In reply to Galen Charlton from comment #17)
> General question about this proposed feature: what's wrong with using the
> cart for this?

The idea is to navigate between selected results, I don't see how to do that with the cart.
When I open the basket, I can see a biblio list but the detail page is opened in a new window.
Even if I improve the behavior, on a ux point of view I think it is not friendly to have to put biblios in the cart for browsing them.
Moreover the same enhancement is developed for authorities (bug 11311), which can not be put in the cart.

Hm, I just took a look at the feature and I think I found a problem:

1) The feature should not be active, when OpacBrowseResults is turned off. Maybe there should even be a separate pref to control this independently from OpacBrowseResults. People are worried about the use of cookies in some contexts and it might be nice to limit the use of them to a mininum.

2) I wonder if the plugin used needs to be added to the about.pl page - not sure there. It also states alpha, but it does look like there is a stable version available now: https://code.google.com/p/jquery-json/

3) While this feature is a bit fun to use, I wonder a bit about the use cases. Maybe the sponsoring library/libraires could share the idea behind the feature?

4) Currently the feature seems to do less than the cart or the list functionality offer, as there are no 'bulk' actions available, so I can understand what Galen means with his comment. 

5) Also it changes the behaviour of an existing feature, which might be a bit unexpected to users. Not sure what we could do here.

6) When switching between different records you always have to reopen the "Browse results" area and this hides part of the possible actions on the page. This way you can't switch really fast between records and have to find your place in the list again.

I think the first point is a 'Failed QA'.

(In reply to Katrin Fischer from comment #20)
> Hm, I just took a look at the feature and I think I found a problem:
> 
> 1) The feature should not be active, when OpacBrowseResults is turned off.
> Maybe there should even be a separate pref to control this independently
> from OpacBrowseResults. People are worried about the use of cookies in some
> contexts and it might be nice to limit the use of them to a mininum.

> 2) I wonder if the plugin used needs to be added to the about.pl page - not
> sure there. It also states alpha, but it does look like there is a stable
> version available now: https://code.google.com/p/jquery-json/

I will provide a followup for these 2 points.

> 3) While this feature is a bit fun to use, I wonder a bit about the use
> cases. Maybe the sponsoring library/libraires could share the idea behind
> the feature?

I will ask the customer for an answer.

> 4) Currently the feature seems to do less than the cart or the list
> functionality offer, as there are no 'bulk' actions available, so I can
> understand what Galen means with his comment. 

The goal is to browse results, not to export them or any other actions.

> 5) Also it changes the behaviour of an existing feature, which might be a
> bit unexpected to users. Not sure what we could do here.

I am not sure that it changes the existing feature. If you click on a detail link (from the result list), you browse all results. If you want to browse selected biblios, you have to click on the new link "browse selected biblios" above the result list. It is 2 different features (but using the same browser UI).

> 6) When switching between different records you always have to reopen the
> "Browse results" area and this hides part of the possible actions on the
> page. This way you can't switch really fast between records and have to find
> your place in the list again.

Yes, it is the current behavior. I think this feature should be used using the next/previous links.

(In reply to Katrin Fischer from comment #20)
> 2) I wonder if the plugin used needs to be added to the about.pl page - not
> sure there.

I am not sure neither.

The purpose of this patch is to give the possibility to users to select some results while browsing the results pages without going to the detail page immediately. After having browsed the results, the users can display the selected results and navigate through them.

Some prelimary QA comments/questions:

From a functional perspective: I would like to see this feature in Koha. In earlier comments some mentioned the cart. But this is an interesting addition! Note also that I more than once heard the question: Why does Koha not remember the items I selected on another search result page? So even without browsing, you make some people happy.
If you browse the selection, it would imo be good to show that you are doing so (Browse selected results vs. Browse results).
If we use the js plugin, it would be good to acknowledge that on About, separate from the question if this specific MIT license needs that by law or so.
Also I do not think that remembering a few biblios in a cookie, would be a big legal problem. We c/should clear the contents every time we start a new search. And if we are not allowed to create it, well we do not.. (We have some laws in the Netherlands too about confirming the use of cookies, but in the meantime things seem to go already in a less 

More technically:
There is a small merge conflict in koha-tmpl/opac-tmpl/prog/en/css/opac.css.
Note that I would like to see the bootstrap patch here also instead of on another report. Bootstrap is now leading and should be pushed first. (Is there any trouble there with less files?) 
From a "minimalistic approach" I do wonder if we really need a new plugin (156 lines) for storing just a few checkboxes (no offense). This is more a personal opinion too and would not be blocking. But could you on the other hand make more clear why we definitely need this plugin and cannot do it with what we have now [ within say 156 lines of code :) ] ?

Waiting for some feedback. Thanks.

in a less -> in a less restrictive way

(In reply to M. de Rooy from comment #26)
> Some prelimary QA comments/questions:

Thank you Marcel for having a look at this one.

> If you browse the selection, it would imo be good to show that you are doing
> so (Browse selected results vs. Browse results).

Will be fixed.

> If we use the js plugin, it would be good to acknowledge that on About,
> separate from the question if this specific MIT license needs that by law or
> so.

In fact the plugin is useless, I will remove it.

> Also I do not think that remembering a few biblios in a cookie, would be a
> big legal problem. We c/should clear the contents every time we start a new
> search. And if we are not allowed to create it, well we do not..

How do we know if we are allowed or not?

> More technically:
> There is a small merge conflict in koha-tmpl/opac-tmpl/prog/en/css/opac.css.

Will be fixed.

> Note that I would like to see the bootstrap patch here also instead of on
> another report. Bootstrap is now leading and should be pushed first. (Is
> there any trouble there with less files?)

The first patches were signed off, so I prefer to create another report for the bootstrap theme.
I will add the patch from bug 11296 to this one.

*** Bug 11296 has been marked as a duplicate of this bug. ***

Jonathan:
Thanks for your adjustments and your patience in looking at what follows :)

I would strongly prefer to slightly adjust a few patches here.
We now add the plugin, update it and then remove it in this series..
I would not recommend to push that line of action if we can just remove it from the first patch. I have no objection to leaving the original signoff on that one when you enter your additional signoff commenting on the amend.
After that I will add still another signoff.
Makes that sense?

Changing status to reflect this.. Please change back to SO after that.

(In reply to M. de Rooy from comment #40)
> I would strongly prefer to slightly adjust a few patches here.
> We now add the plugin, update it and then remove it in this series..
> I would not recommend to push that line of action if we can just remove it
> from the first patch. I have no objection to leaving the original signoff on
> that one when you enter your additional signoff commenting on the amend.
> After that I will add still another signoff.
> Makes that sense?

Absolutely, it was a "morning laziness" :)
I completely removed all references to this plugin in the last set of patches.

Some comments after experimenting the feature further on bootstrap/prog. Should we still put time in ccsr?

1. If you disable OpacBrowseResults, please remove the link.
2. In bootstrap clicking Browse selected on detail page does not respond (prog does)
3. This is a weird one but just mentioning: Disable cookies in your browser. Check two biblios on the same page. Click on Browse selected. No item was selected. Heh. If you cannot save the cookie, remove link too? Note that by checking the cookie again in setContextBiblioNumbers, you know if the first call succeeded or not.

Waiting for some feedback. After that I will still have to look at the code somewhat more closely..

(In reply to M. de Rooy from comment #50)

> 1. If you disable OpacBrowseResults, please remove the link.

Fixed

> 2. In bootstrap clicking Browse selected on detail page does not respond
> (prog does)

Cause by a bad merge conflict reintroduced by last set of patches. Fixed!

> 3. This is a weird one but just mentioning: Disable cookies in your browser.
> Check two biblios on the same page. Click on Browse selected. No item was
> selected. Heh. If you cannot save the cookie, remove link too? Note that by
> checking the cookie again in setContextBiblioNumbers, you know if the first
> call succeeded or not.

Fixed too with the last patch. There were some weird behaviors if javascript was deactivated or cookies disabled.

QA Comment:
Nice work including QA changes. No complaints from koha-qa. 

Tested prog and bootstrap. Disabled cookies too for a short while :) 

Still found small debatable issue: 
First I selected one record on page 1, page 2 and page 3. After that I selected all records on page 1. 
It confused me at first to discover that the Browse results on detail are not in the order of the search results, but apparently in the order of being added to the list. 
No blocker for me, but we could argue about the order of the list. 

One of the commit messages promised this: 
  In addition to prog and ccsr templates, this patch allows to add 
  selected biblios (from multiple pages) to the cart or a list. 
  To test: 
  - check some biblios from several pages 
  - add them to the cart 
  - add them to a list 
Unfortunately, when I added items from two pages, only the item of the current page was added. 
Again (with this being my last QA before temporary cutoff date) no blocker for me :) 
A followup would be pretty on another report though.  

Saw some warnings in the log: 
opac-detail.pl: Use of uninitialized value in concatenation (.) or string at /usr/share/koha/testclone/opac/opac-detail.pl line 394 
opac-detail.pl: Use of uninitialized value in concatenation (.) or string at /usr/share/koha/testclone/opac/opac-detail.pl line 400. 
But I have the impression that your patches did not touch these lines.. 

Passed QA

(In reply to M. de Rooy from comment #66)
> One of the commit messages promised this: 
>   In addition to prog and ccsr templates, this patch allows to add 
>   selected biblios (from multiple pages) to the cart or a list. 
>   To test: 
>   - check some biblios from several pages 
>   - add them to the cart 
>   - add them to a list 
> Unfortunately, when I added items from two pages, only the item of the
> current page was added. 

I just retested right now and it works using the bootstrap theme.

This set up rather a lot of infrastructure for a feature whose workflow purpose can be met by the cart, and I remain dubious.  Consequently, I'm punting this to the next RM.

I removed the "in discussion" status. Sent to the RM queue.

Dear RM, what about this feature? :)

Ok so, back on this one.
It did not apply at all and had ccsr+prog themes.
This new patch is just a squash patch with only the bootstrap theme changes.
Test plan is the same.

QA Note:(In reply to M. de Rooy from comment #26)
> If you browse the selection, it would imo be good to show that you are doing
> so (Browse selected results vs. Browse results).

I removed this change, it did not work.
Actually I don't see an easy way to do that and consider it as a minor and should not be a blocker.

Switch back in the QA queue to give confidence to the RM.

CONFLICT (add/add): Merge conflict in koha-tmpl/opac-tmpl/bootstrap/lib/jquery/plugins/jquery.cookie.min.js
Auto-merging koha-tmpl/opac-tmpl/bootstrap/js/basket.js
Auto-merging koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-results.tt
CONFLICT (content): Merge conflict in koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-results.tt

1) Shoudl this be included on the about.pl page?
+// Extends jQuery API
+// http://www.wskidmore.com/downloads/jquery-uniqueArray.min.js

2) I think there are display problems, when both the cart and the lists are turned off:

For example, this is only available with the prefs ON:
 var MSG_NO_RECORD_SELECTED = _("No item was selected");

Browse selected record still shows up, but I see only one checkbox on my third record in the list? (confusing)

I am not logged in and tried in 2 different browsers.

(In reply to Katrin Fischer from comment #75)
> 1) Shoudl this be included on the about.pl page?
> +// Extends jQuery API
> +// http://www.wskidmore.com/downloads/jquery-uniqueArray.min.js

The domain is down and I don't know at all where I found this piece of code.
It was certainly under the MIT license.

> 2) I think there are display problems, when both the cart and the lists are
> turned off:
> 
> For example, this is only available with the prefs ON:
>  var MSG_NO_RECORD_SELECTED = _("No item was selected");

Ok fixed.

> Browse selected record still shows up, but I see only one checkbox on my
> third record in the list? (confusing)
> 
> I am not logged in and tried in 2 different browsers.

I don't get it, I have never seen that.
Please provide more info to recreate the issue.

> > 1) Shoudl this be included on the about.pl page?
> > +// Extends jQuery API
> > +// http://www.wskidmore.com/downloads/jquery-uniqueArray.min.js
> 
> The domain is down and I don't know at all where I found this piece of code.
> It was certainly under the MIT license.

I am not very comfortable with the dependency as it doesn't include a lisence statement right now and there seems no way to trace it back to an author. Could we replace this with our own code or some other plugin?

Some of the other problems went away after making sure my browser cache was cleared. But I still see a problem when both cart and list are turned off: the text "browse selected records" still shows up, but there are no checkboxes to select a record.

(In reply to Katrin Fischer from comment #78)
> Some of the other problems went away after making sure my browser cache was
> cleared. But I still see a problem when both cart and list are turned off:
> the text "browse selected records" still shows up, but there are no
> checkboxes to select a record.

This is still valid.

Hi Jonathan, thx for the follow-up replacing the jQuery! Are we waiting for another follow-up  here?

No sorry, back to Needs QA.

Created attachment 39938 [details]
No way to select records with list and cart inactive - link stil shows

Hi Jonathan, I think the link should disappear when neither cart nor list are available - or we need to keep showing the checkboxes for selecting records in the result list.

Created attachment 41839 [details] [review]
Bug 10858: Browse selected biblios

Rebased on master

Created attachment 41840 [details] [review]
Bug 10858: Define the NO_RECORD_SELECTED msg in any case

Rebased on master

Created attachment 41841 [details] [review]
Bug 10858: Replace the unique jQuery function with our own

Rebased on master

Hi Julian,

I think the last patch makes a wrong assumption - the browse feature is useless if OpacBrowseResults is turned off (which some of our libraries actually have). So I think removing the checks for the checkboxes should be undone and a check for this pref added to the code - for the checkboxes and also for the link at the top of the results.

What do you think?

Hi Katrin,

I made this assumption by looking at the code, but the code is wrong, and you are right ;)
I will submit a followup, replacing the last patch.

On last patch, I don't understand that, the last test:

[% IF
   ( Koha.Preference('opacbookbag') == 1 )
|| ( Koha.Preference('virtualshelves') == 1 )
|| ( Koha.Preference('OpacBrowseResults') == 1 )
|| ( Koha.Preference('RequestOnOpac') == 1 && (not SEARCH_RESULT.norequests) && Koha.Preference('opacuserlogin') )
%]

I think that it's rather:

|| ( Koha.Preference('RequestOnOpac') == 1 && (not SEARCH_RESULT.norequests) && (not Koha.Preference('opacuserlogin')) )

But I'm not sure...

And When everything is disabled, no checkboxes at all, links 'check all' / 'clear all' are still displayed. This bug is also in master, but still...

hm, the last line seems correct to me: if holds and login are allowed...

Created attachment 56479 [details] [review]
Bug 10858: Browse selected biblios

After launching a search, some people would like to browse some results
from several pages.

This patch adds, at the OPAC, a link "Browse selected biblios >>" when
at least one biblio is checked. You can choose biblios from several
page, not the current one. In this way, checkboxes already checked
become again checked when you come back on this results page.
After clicking the link, the "Browse results" block is filled with
selected biblios, not (like as the current behavior) with the classic
results.

Test plan:
- Launch a search at the OPAC
- Check some biblios
- Go on another page
- Check some biblios
- Come back to the first page and check that already checked biblio is
  automatically checked.
- Click on the "Browse selected biblios >>" link
- Check that you are able to browse results you had checked.

You can also:
- check some biblios from several pages
- add them to the cart
- add them to a list

Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>

Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Created attachment 56480 [details] [review]
Bug 10858: Define the NO_RECORD_SELECTED msg in any case

And not only when cart or list are defined.

(In reply to Marcel de Rooy from comment #26)

> If you browse the selection, it would imo be good to show that you are doing
> so (Browse selected results vs. Browse results).

I like this suggestion too, but I think it could be handled in a follow-up.

It looks to me like the contents of common.js could be put into global.js and we could avoid having a separate file. Do you think there is a reason not to?

(In reply to Owen Leonard from comment #98)
> (In reply to Marcel de Rooy from comment #26)
> 
> > If you browse the selection, it would imo be good to show that you are doing
> > so (Browse selected results vs. Browse results).
> 
> I like this suggestion too, but I think it could be handled in a follow-up.
> 
> It looks to me like the contents of common.js could be put into global.js
> and we could avoid having a separate file. Do you think there is a reason
> not to?

These patches have been submitted 3 years ago, and have been rewritten 3 times already. If we want additional behaviours they should go to another bug report.
The commons.js content could be moved to global.js but note that bug 11311 is adding more content to this file. Maybe we could move it to something less vague than 'commons' but keep it apart from global.

(In reply to Jonathan Druart from comment #99)
> These patches have been submitted 3 years ago, and have been rewritten 3
> times already.

Okay that's fair. My comments are not about issues which should block this.

One thing I am concerned about is the behavior of browsing when you have multiple tabs open. Browsing selected records seems to get confused if you perform a search in another tab, with the list of selected records getting replaced by the list of searched records.

Yes indeed, launching several searches in different tabs will give wrong results.
I have no idea how we could fix that.

Doesn't apply in the sandboxes. Could you rebase it? Thank you

Patches rebased on master

Created attachment 67974 [details] [review]
Bug 10858: Browse selected biblios

After launching a search, some people would like to browse some results
from several pages.

This patch adds, at the OPAC, a link "Browse selected biblios >>" when
at least one biblio is checked. You can choose biblios from several
page, not the current one. In this way, checkboxes already checked
become again checked when you come back on this results page.
After clicking the link, the "Browse results" block is filled with
selected biblios, not (like as the current behavior) with the classic
results.

Test plan:
- Launch a search at the OPAC
- Check some biblios
- Go on another page
- Check some biblios
- Come back to the first page and check that already checked biblio is
  automatically checked.
- Click on the "Browse selected biblios >>" link
- Check that you are able to browse results you had checked.

You can also:
- check some biblios from several pages
- add them to the cart
- add them to a list

Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>

Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Created attachment 67975 [details] [review]
Bug 10858: Define the NO_RECORD_SELECTED msg in any case

And not only when cart or list are defined.

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Created attachment 67976 [details] [review]
Bug 10858: Replace the unique jQuery function with our own

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Created attachment 67977 [details] [review]
Bug 10858: Show checkbox if OpacBrowseResult is set

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Created attachment 67978 [details] [review]
Bug 10858: Add 2 missing nav class

Created attachment 71218 [details] [review]
Bug 10858: Browse selected biblios

After launching a search, some people would like to browse some results
from several pages.

This patch adds, at the OPAC, a link "Browse selected biblios >>" when
at least one biblio is checked. You can choose biblios from several
page, not the current one. In this way, checkboxes already checked
become again checked when you come back on this results page.
After clicking the link, the "Browse results" block is filled with
selected biblios, not (like as the current behavior) with the classic
results.

Test plan:
- Launch a search at the OPAC
- Check some biblios
- Go on another page
- Check some biblios
- Come back to the first page and check that already checked biblio is
  automatically checked.
- Click on the "Browse selected biblios >>" link
- Check that you are able to browse results you had checked.

You can also:
- check some biblios from several pages
- add them to the cart
- add them to a list

Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>

Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 71219 [details] [review]
Bug 10858: Define the NO_RECORD_SELECTED msg in any case

And not only when cart or list are defined.

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 71220 [details] [review]
Bug 10858: Replace the unique jQuery function with our own

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 71221 [details] [review]
Bug 10858: Show checkbox if OpacBrowseResult is set

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 71222 [details] [review]
Bug 10858: Add 2 missing nav class

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 71223 [details] [review]
Bug 10858: (QA follow-up) Fix translatibility

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

As bug 19290 adds a new pref to turn the feature on/off, should not we do the same for the OPAC?

(In reply to Jonathan Druart from comment #124)
> As bug 19290 adds a new pref to turn the feature on/off, should not we do
> the same for the OPAC?

To me, that would be more logical.

failed with new JS name scheme.

Created attachment 91584 [details] [review]
Bug 10858: Browse selected biblios

After launching a search, some people would like to browse some results
from several pages.

This patch adds, at the OPAC, a link "Browse selected biblios >>" when
at least one biblio is checked. You can choose biblios from several
page, not the current one. In this way, checkboxes already checked
become again checked when you come back on this results page.
After clicking the link, the "Browse results" block is filled with
selected biblios, not (like as the current behavior) with the classic
results.

Test plan:
- Launch a search at the OPAC
- Check some biblios
- Go on another page
- Check some biblios
- Come back to the first page and check that already checked biblio is
  automatically checked.
- Click on the "Browse selected biblios >>" link
- Check that you are able to browse results you had checked.

You can also:
- check some biblios from several pages
- add them to the cart
- add them to a list

Signed-off-by: Cedric Vita <cedric.vita@dracenie.com>

Signed-off-by: Koha Team Amu <koha.aixmarseille@gmail.com>

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 91585 [details] [review]
Bug 10858: Define the NO_RECORD_SELECTED msg in any case

And not only when cart or list are defined.

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 91586 [details] [review]
Bug 10858: Replace the unique jQuery function with our own

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 91587 [details] [review]
Bug 10858: Show checkbox if OpacBrowseResult is set

Signed-off-by: Nicolas Legrand <nicolas.legrand@bulac.fr>

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 91588 [details] [review]
Bug 10858: Add 2 missing nav class

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Created attachment 91589 [details] [review]
Bug 10858: (QA follow-up) Fix translatibility

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>

Why not add the JS in the new common.js file to global.js?

It doesn't look like there is a way to clear your selection. Is it necessary to uncheck each selected record?

When I apply the patch, the 'selections-toolbar' is emptied of all its options.
See screenshot attached.

Created attachment 94833 [details]
No option visible with patch applied

First screenshot = master
Second screenshot = patch 10585 applied, all the options are hidden