Bug 13371

Summary: Add filters to the supplier list view
Product: Koha Reporter: Jonathan Druart <jonathan.druart>
Component: AcquisitionsAssignee: claire.hernandez <claire.hernandez>
Status: Failed QA --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: alex.arnaud, josef.moravec, julian.maurice, katrin.fischer, koha, m.de.rooy, matthias.meusburger, mchen, oleonard, paola.rossi, veron
Version: master   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11215
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28922
Change sponsored?: --- Patch complexity: Medium patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 13369, 13370    
Bug Blocks:    
Attachments: Bug 13371: Add filters on the supplier list view
Bug 13371: Reintroduce the action buttons
Bug 13371: Add a filter for opened baskets
Bug 13371: change the filters wording
New screen/table for booksellers.pl
Bug 13371: just a test for the biblio|item count filters
Bug 13371: Add filters on the supplier list view
Bug 13371: Reintroduce the action buttons
Bug 13371: Add a filter for opened baskets
Bug 13371: change the filters wording
Bug 13371: just a test for the biblio|item count filters
Bug 13371: List suppliers even if they don't have basket.
Bug 13371: List suppliers even if they don't have basket.
Bug 13371: Fix filtering on numbers
Bug 13371: Move firstname and surname closer
Bug 13371: Add filters on the supplier list view
Bug 13371: Reintroduce the action buttons
Bug 13371: Add a filter for opened baskets
Bug 13371: change the filters wording
Bug 13371: List suppliers even if they don't have basket.
Bug 13371: Fix filtering on numbers
Bug 13371: Move firstname and surname closer
Bug 13371: Add a simple view
Bug 13371: Add filters on the supplier list view
Bug 13371: Reintroduce the action buttons
Bug 13371: Add a filter for opened baskets
Bug 13371: change the filters wording
Bug 13371: List suppliers even if they don't have basket.
Bug 13371: Fix filtering on numbers
Bug 13371: Move firstname and surname closer
Bug 13371: Add a simple view
Bug 13371: Add filters on the supplier list view
Bug 13371: Reintroduce the action buttons
Bug 13371: Add a filter for opened baskets
Bug 13371: change the filters wording
Bug 13371: List suppliers even if they don't have basket.
Bug 13371: Fix filtering on numbers
Bug 13371: Move firstname and surname closer
Bug 13371: Add a simple view
Bug 13371: Re-add what was lost in the rebase process
Bug 13371: calendar.inc needed for date-range filter to parse dates correctly
Bug 13371: Add filters on the supplier list view
Bug 13371: Add filters on the supplier list view
Bug 13371: Add filters on the supplier list view

Description Jonathan Druart 2014-12-02 11:05:55 UTC
The supplier list view does not permit to filter on opened/closed baskets, creator name, basketgroup name or dates.
That can be added easily using the DataTables filters.

This new enhancement will allow a librarian to filter the supplier/basket list view.
Comment 1 Jonathan Druart 2014-12-02 11:10:40 UTC Comment hidden (obsolete)
Comment 2 Jonathan Druart 2014-12-02 11:10:44 UTC Comment hidden (obsolete)
Comment 3 Jonathan Druart 2014-12-02 11:14:38 UTC
Note that this enhancement can be tested without patches from bug 13369 and bug 13370.
They are only 2 small ergonomic improvements.
Comment 4 Jonathan Druart 2014-12-02 11:37:31 UTC Comment hidden (obsolete)
Comment 5 Matthias Meusburger 2014-12-05 15:46:49 UTC
About the baskets filters:

If I click on "Show active baskets only" then on "Show opened baskets only" I end up with two "Show all baskets" links one after the other.

This is confusing.

Imho, it should work this way:

Show active baskets only -> click -> Show active and inactive baskets
Show opened baskets only -> click -> Show opened and closed baskets

This way the user knows exactly what is filtered.


About the datatable filters:

'Item count' and 'Biblio count' didn't work for me: "No matching records found" (some records should have matched my search).
Comment 6 Jonathan Druart 2014-12-08 09:03:47 UTC Comment hidden (obsolete)
Comment 7 Jonathan Druart 2014-12-08 09:06:42 UTC
(In reply to Matthias Meusburger from comment #5)
> About the baskets filters:
> 
> If I click on "Show active baskets only" then on "Show opened baskets only"
> I end up with two "Show all baskets" links one after the other.
> 
> This is confusing.
> 
> Imho, it should work this way:
> 
> Show active baskets only -> click -> Show active and inactive baskets
> Show opened baskets only -> click -> Show opened and closed baskets

It makes sense, thanks for the suggestion!

> About the datatable filters:
> 
> 'Item count' and 'Biblio count' didn't work for me: "No matching records
> found" (some records should have matched my search).

I don't encounter this issue.
But I marked these fields as integer. It means that if a cell contains "2 (1 canceled)", it will only appear if you search for '2'. This is a feature but can be removed if considered as a bug.
Comment 8 Jonathan Druart 2014-12-08 11:47:03 UTC
Created attachment 34170 [details]
New screen/table for booksellers.pl
Comment 9 Paola Rossi 2014-12-09 17:19:48 UTC
I've applied the patches [13369,13370,13371] against 3.19.00.000

'Item count' and 'Biblio count' didn't yet work:
"No matching records found" (even if some records matched my search).

So I pass the patch to "Failed QA" status.

NB1. A patron "Xa" of the library "Yb" had created the basket. In the "Created by" column of that basket I saw:
XaYb (without spaces).
I think that the value "Xa Yb" would be preferred; otherwise filtering "aY" would find that row (ERROR).

NB2. On koha/acqui/acqui-home.pl I wrote nothing in vendor's field.
Koha answered the default list of the vendor/baskets. It was:

You searched on vendor , 10 results found
Show active and inactive baskets | Show opened baskets only
Showing 1 to 6 of 6

Was the result 10 or 6? 
It's not so clear at once that the 4 missing baskets are the inactive ones. [I myself went early in confusion while I was testing, see below NB4.]
Remember that on master the default is the complete list of vendors: if a vendor has only one inactive basket, the vendor is not listed at all!
So the deault filter chosen in this bug:
Show active and inactive baskets | Show opened baskets only
didn't correspond to the current default of master.

NB3. Same search as NB2, on the empty-vendor list's answer.
One vendor of mine was "inactive". But I saw it in the list of vendors.
So an "inactive" basket is not the basket of an "inactive" vendor.
So, I'm in doubt: what is an "inactive"/"active" basket?
Some of the listed baskets had still expected items > 0: they're active, aren't they?
But an open basket had 0 biblio, 0 items, 0 expected items: it was listed as active. Is it right?

NB4. On ACQ home, I saw for the table of funds:
Hide inactive budgets | Show inactive budgets

Imho the use of the same kind of filters might perhaps be clearer:
Show inactive baskets | Hide inactive baskets | Show closed baskets | Hide closed baskets

NB5. In a closed basket, 1 item was ordered, 1 item was partial and 1 item was completely received.
When I selected only the active baskets, the item count is 2.
When both the active and inactive baskets were selected, the item count is 3.
I'm in doubt: is it right?

NB6. "Expected items" might be preferred to "Items expected".
Comment 10 Jonathan Druart 2014-12-10 09:59:10 UTC
(In reply to Paola Rossi from comment #9)
> I've applied the patches [13369,13370,13371] against 3.19.00.000
> 
> 'Item count' and 'Biblio count' didn't yet work:
> "No matching records found" (even if some records matched my search).

Weird, I don't have this problem.
What is the version of your browser?
Could you make a screenshot/screencast?

> NB1. A patron "Xa" of the library "Yb" had created the basket. In the
> "Created by" column of that basket I saw:
> XaYb (without spaces).
> I think that the value "Xa Yb" would be preferred; otherwise filtering "aY"
> would find that row (ERROR).

Hum, the "created by" column should only contain firstname + surname.

> NB2. On koha/acqui/acqui-home.pl I wrote nothing in vendor's field.
> Koha answered the default list of the vendor/baskets. It was:
> 
> You searched on vendor , 10 results found
> Show active and inactive baskets | Show opened baskets only
> Showing 1 to 6 of 6
>
> Was the result 10 or 6? 

Actually it's 10 vendors and 6 baskets.

> It's not so clear at once that the 4 missing baskets are the inactive ones.
> [I myself went early in confusion while I was testing, see below NB4.]
> Remember that on master the default is the complete list of vendors: if a
> vendor has only one inactive basket, the vendor is not listed at all!
> So the deault filter chosen in this bug:
> Show active and inactive baskets | Show opened baskets only
> didn't correspond to the current default of master.

Does my previous answer correct the confusion?

> NB3. Same search as NB2, on the empty-vendor list's answer.
> One vendor of mine was "inactive". But I saw it in the list of vendors.
> So an "inactive" basket is not the basket of an "inactive" vendor.
> So, I'm in doubt: what is an "inactive"/"active" basket?
> Some of the listed baskets had still expected items > 0: they're active,
> aren't they?
> But an open basket had 0 biblio, 0 items, 0 expected items: it was listed as
> active. Is it right?

A basket is considered as inactive if it is closed and no item is expected (should not be different as before this patch set).
Before this patch, a "Show all baskets" existed. I have just renamed it, but the behavior should be the same.

> NB4. On ACQ home, I saw for the table of funds:
> Hide inactive budgets | Show inactive budgets
> 
> Imho the use of the same kind of filters might perhaps be clearer:
> Show inactive baskets | Hide inactive baskets | Show closed baskets | Hide
> closed baskets

I am not sure. IMO it is more confusing.
But we could ask Owen what he thinks about it.

> NB5. In a closed basket, 1 item was ordered, 1 item was partial and 1 item
> was completely received.
> When I selected only the active baskets, the item count is 2.
> When both the active and inactive baskets were selected, the item count is 3.
> I'm in doubt: is it right?

It looks like a bug and it's certainly in master too.
Could you open a new bug report, describe the problem and assign it to me please?

> NB6. "Expected items" might be preferred to "Items expected".

It does not come from this patch, it's the same string as before.
It could be fix on the QA step if needed.
Comment 11 Jonathan Druart 2014-12-10 09:59:44 UTC Comment hidden (obsolete)
Comment 12 Jonathan Druart 2014-12-10 10:00:37 UTC
(In reply to Paola Rossi from comment #9)
> I've applied the patches [13369,13370,13371] against 3.19.00.000
> 
> 'Item count' and 'Biblio count' didn't yet work:
> "No matching records found" (even if some records matched my search).

Could you please test with the last patch I submitted?
Since I don't reproduce the issue, it's not easy to fix it :-/
Comment 13 Paola Rossi 2014-12-10 17:04:03 UTC
(In reply to Jonathan Druart from comment #10)
> (In reply to Paola Rossi from comment #9)
[...] 
> > NB1. A patron "Xa" of the library "Yb" had created the basket. In the
> > "Created by" column of that basket I saw:
> > XaYb (without spaces).
> > I think that the value "Xa Yb" would be preferred; otherwise filtering "aY"
> > would find that row (ERROR).
> 
> Hum, the "created by" column should only contain firstname + surname.
> 

NB1. was my fault! I beg your pardon, I'm sorry.

> Before this patch, a "Show all baskets" existed. I have just renamed it, but
> the behavior should be the same.
> 
I thought there was a difference on master and after fixing. I don't know if it's meaningful or not, so I try to describe this difference with plainness.

Before this patch, on master, the function was a selection about vendors, not about baskets.
All the vendors were shown. And then their baskets were shown if they were of the right kind. Before this patch, the "Show all baskets" didn't change [didn't increase] the listed vendors, but only increased the shown baskets. At first, some vendors could be listed with no basket at all.

After this patch koha doesn't show a vendor when no basket of his is of the right kind.
Comment 14 Jonathan Druart 2014-12-11 08:16:04 UTC
(In reply to Paola Rossi from comment #13)
> Before this patch, on master, the function was a selection about vendors,
> not about baskets.
> All the vendors were shown. And then their baskets were shown if they were
> of the right kind. Before this patch, the "Show all baskets" didn't change
> [didn't increase] the listed vendors, but only increased the shown baskets.
> At first, some vendors could be listed with no basket at all.
> 
> After this patch koha doesn't show a vendor when no basket of his is of the
> right kind.

Yes, you are right to raise this difference, I should have done it!
Actually I was thinking about changing the name of this script, especially because it's more a basket search than a bookseller search.

Do you think we should display all suppliers even if they don't have a basket listed?
I am not sure it will be easier to display them in the table.
Comment 15 Katrin Fischer 2014-12-11 08:39:37 UTC
> Do you think we should display all suppliers even if they don't have a
> basket listed?
> I am not sure it will be easier to display them in the table.

I think we need to list those without baskets, because otherwise I think you won't be able to start a new order for a newly added vendo

While we always displayed the baskets, I am a bit worried that the display will get confusing for the 'create new order' step with it being a table. When you create a new order, the first thing you do is to look up your vendor in Koha - you are not interested in most of the displayed information then, apart from the 'new basket' link - so it is in fact a vendor search too.

Maybe there should be a short and a long form of the result list?
Comment 16 Jonathan Druart 2014-12-11 09:39:28 UTC Comment hidden (obsolete)
Comment 17 Jonathan Druart 2014-12-11 09:39:32 UTC Comment hidden (obsolete)
Comment 18 Jonathan Druart 2014-12-11 09:39:35 UTC Comment hidden (obsolete)
Comment 19 Jonathan Druart 2014-12-11 09:39:38 UTC Comment hidden (obsolete)
Comment 20 Jonathan Druart 2014-12-11 09:39:41 UTC Comment hidden (obsolete)
Comment 21 Jonathan Druart 2014-12-11 10:50:55 UTC Comment hidden (obsolete)
Comment 22 Jonathan Druart 2014-12-11 10:51:32 UTC
(In reply to Jonathan Druart from comment #21)
> Created attachment 34306 [details] [review] [review]
> Bug 13371: List suppliers even if they don't have basket.

This patch proposes a solution for suppliers without basket.
Comment 23 Paola Rossi 2014-12-11 11:18:52 UTC
(In reply to Jonathan Druart from comment #10)
> (In reply to Paola Rossi from comment #9)
[...]

Thanks, Jonathan.

NB1), NB2) and NB3) of comment #9 and #10 are allright.
NB4) and NB6) have already been taken in care and are being to study at present.
About NB5) I'll make some tests on master asap, thanks again.
Comment 24 Paola Rossi 2014-12-11 11:36:20 UTC
(In reply to Jonathan Druart from comment #12)

> > 
> > 'Item count' and 'Biblio count' didn't yet work:
> > "No matching records found" (even if some records matched my search).
> 
> Could you please test with the last patch I submitted?
> Since I don't reproduce the issue, it's not easy to fix it :-/

I've applied the today's version of the patch against master 3.19.00.000 .
The error still occurred, either with or without the 5-th patch "just a test..".
It happened using:
FF 34.0.5, IE 11, GCh Version 39.0.2171.95 m

[The error occurred even yesterday [applying the previuos version of the patches] even applying the 5-th patch "just a test ..." , sorry for my delay.]

Applying the patches is ok at my tests.

The first 13771 patch required an auto-merging:
Applying: Bug 13371: Add filters on the supplier list view
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/intranet-tmpl/prog/en/css/datatables.css

I've made some tests but I unfortunately have not yet got anything helping imo.

2) About searching vendors: 
I searched vendors without baskets [using "Vendor search"]:
If 1 vendor had no baskets in DB, koha answered nothing about results found, showing no vendor and "No data available in table"; but also showing "+New" [basket/contract/vendor] "Edit vendor" "Receive shipments" (all useful and about that vendor) on top of the table [it's partially right: it's wrong because the name is not seen].
If 2 vendor had no baskets in DB, koha answered with "2 results found", showing no vendor "No data available in table", and nothing else.

I pass this patch to "Failed QA" status.
Comment 25 Paola Rossi 2014-12-11 11:45:13 UTC
Sorry, my comment 24 didn't take in care the Jonathan's comment 22.

I pass the patch back to "Needs Signoff" status.
Comment 26 Paola Rossi 2014-12-11 15:20:43 UTC
I've applied the patches  [13369,13370,13371 6] against master 3.19.00.000 .

Now vendors with no basket have been listed, as desired.

At first, by default options [=Show active and inactive baskets | Show opened baskets only] :
at a vendor without active basket 1 row has been attached: "No active basket"
at a vendor without basket at all 1 row has been attached: "No active basket"

by these options : Show active baskets only| Show opened baskets only :
at a vendor without active basket 1 row has been attached: "No active basket"
at a vendor without basket at all 1 row has been attached: "No basket"

In "Showing 1 to X of X", X counted the rows [not only the real baskets, but even the "No basket" rows].

1) 'Item count' and 'Biblio count' didn't yet work:
"No matching records found" (even if some records matched my search).
It happened using:
FF 34.0.5, IE 11, GCh Version 39.0.2171.95 m

[The installed version of :
jquery.dataTables.columnFilter.js
* Version:     1.5.0.]

2) > [...] the "created by" column should contain firstname + surname.
So I've filtered by "firstname surname" values: ERROR: 
No matching records found

Consequently, on certain names [i.e. surnames such as "de Roy", or firstnames such as "Maria Luisa"], filtering had the same error as above: ERROR.

On the contrary, filtering by only a firstname, or filtering by only a surname, is OK.

So I pass the patch to "Failed QA" status.
Comment 27 Jonathan Druart 2014-12-15 13:58:11 UTC Comment hidden (obsolete)
Comment 28 Jonathan Druart 2014-12-15 13:58:17 UTC Comment hidden (obsolete)
Comment 29 Jonathan Druart 2014-12-15 13:58:23 UTC Comment hidden (obsolete)
Comment 30 Jonathan Druart 2014-12-15 14:00:16 UTC
(In reply to Paola Rossi from comment #26)
> 1) 'Item count' and 'Biblio count' didn't yet work:
> "No matching records found" (even if some records matched my search).
> It happened using:
> FF 34.0.5, IE 11, GCh Version 39.0.2171.95 m

I finally reproduced the problem on a sandbox (so same browser and same code, only data have changed).
Fix submitted (Bug 13371: Fix filtering on numbers).

> 2) > [...] the "created by" column should contain firstname + surname.
> So I've filtered by "firstname surname" values: ERROR: 
> No matching records found

Fixed too (Bug 13371: Move firstname and surname closer).
Comment 31 Paola Rossi 2014-12-15 16:01:04 UTC Comment hidden (obsolete)
Comment 32 Paola Rossi 2014-12-15 16:01:34 UTC Comment hidden (obsolete)
Comment 33 Paola Rossi 2014-12-15 16:02:45 UTC Comment hidden (obsolete)
Comment 34 Paola Rossi 2014-12-15 16:03:13 UTC Comment hidden (obsolete)
Comment 35 Paola Rossi 2014-12-15 16:03:46 UTC Comment hidden (obsolete)
Comment 36 Paola Rossi 2014-12-15 16:04:24 UTC Comment hidden (obsolete)
Comment 37 Paola Rossi 2014-12-15 16:04:59 UTC Comment hidden (obsolete)
Comment 38 Owen Leonard 2015-01-06 15:01:02 UTC
I'm looking at this now for the first time, so my comments may come to late. But I think this isn't an improvement from a usability point of view. Combining each of the separate vendor tables into one makes the page much more difficult to scan. Are we trying to do too much on this page? Should we be focusing instead on adding filtering or advanced searching options to the order search page?

I think it would be good to talk about what the expected workflow is here. I don't use acquisitions in production so I don't work with real data when I'm testing. I probably make incorrect assumptions about how people do things.

The page seems to offer several end points:

1. Finding a vendor so you can view the details of that vendor
2. Showing a list of open baskets so that you can view one
3. Showing a list of open baskets so that you can add to one
4. Showing a list of basket groups so that you can view one

If that's correct, then adding filtering should improve the ease of reaching one of those goals:

1. Finding a vendor -- I assume this isn't really a priority because we reach this page *from* a vendor search.
2. & 3. Finding a basket. Do we need to filter by basket information because we know the basket information but not the vendor? If we assume that we know the vendor and want to find a basket then we should keep the view which keeps each vendor in a separate table. If we assume that we're searching by basket information but *don't* know the vendor then we need to filter across all baskets.
4. Finding a basket group -- same questions as with 2. & 3. Can we assume that the vendor is known, or is it the case that sometimes only the basket group information is known?
Comment 39 Katrin Fischer 2015-01-29 07:17:03 UTC
Maybe we could get some librarians to take a look here?

My worry is that the new table will make the process of finding the vendor to start an order for slower, because it's harder to scan the table than to scan through individual entries in a list. 

Could we have a simple and an advanced view for this page?
Comment 40 Jonathan Druart 2015-01-29 09:32:05 UTC
(In reply to Katrin Fischer from comment #39)
> Could we have a simple and an advanced view for this page?

How do you imagine the simple view?
Comment 41 Jonathan Druart 2015-03-10 10:28:11 UTC Comment hidden (obsolete)
Comment 42 Marcel de Rooy 2015-04-17 07:21:27 UTC
Switching this back to Needs Signoff, looking at the discussion in the last comments and the addition of the last patch.
Comment 43 Koha Team University Lyon 3 2015-12-15 15:44:50 UTC
Tried on a sandbox :
Some problems occurred applying patches from bug 13371:
<h1>Something went wrong !</h1>Applying: Bug 13371: Add filters on the supplier list view
fatal: sha1 information is lacking or useless (koha-tmpl/intranet-tmpl/prog/en/css/datatables.css).
Comment 44 Alex Arnaud 2016-03-11 13:58:36 UTC Comment hidden (obsolete)
Comment 45 Alex Arnaud 2016-03-11 13:58:43 UTC Comment hidden (obsolete)
Comment 46 Alex Arnaud 2016-03-11 13:58:51 UTC Comment hidden (obsolete)
Comment 47 Alex Arnaud 2016-03-11 13:59:00 UTC Comment hidden (obsolete)
Comment 48 Alex Arnaud 2016-03-11 13:59:07 UTC Comment hidden (obsolete)
Comment 49 Alex Arnaud 2016-03-11 13:59:15 UTC Comment hidden (obsolete)
Comment 50 Alex Arnaud 2016-03-11 13:59:23 UTC Comment hidden (obsolete)
Comment 51 Alex Arnaud 2016-03-11 13:59:29 UTC Comment hidden (obsolete)
Comment 52 Alex Arnaud 2016-03-11 14:05:49 UTC
Patches rebased. A test is needed now
Comment 53 Jonathan Druart 2016-03-11 14:13:14 UTC
(In reply to Alex Arnaud from comment #52)
> Patches rebased. A test is needed now

Thanks Alex for having revived this amazing patch set ;)
Comment 54 Owen Leonard 2016-03-17 12:54:59 UTC
Are the table columns in the detailed view supposed to be sortable?
Comment 55 Jonathan Druart 2016-03-18 10:20:07 UTC
(In reply to Owen Leonard from comment #54)
> Are the table columns in the detailed view supposed to be sortable?

No, iirc it's not feasible (same problematic as the fund lists on admin/aqbudgets.pl and acqui/acqui-home.pl).
Comment 56 Koha Team University Lyon 3 2016-03-24 15:04:11 UTC
Tried on sandbox :

Some problems occurred applying patches from bug 13371:
<h1>Something went wrong !</h1>Applying: Bug 13371: Add filters on the supplier list view Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/acqui/booksellers.tt
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/acqui/booksellers.tt
Failed to merge in the changes.
Patch failed at 0001 Bug 13371: Add filters on the supplier list view
Comment 57 Julian Maurice 2016-09-06 10:40:00 UTC Comment hidden (obsolete)
Comment 58 Julian Maurice 2016-09-06 10:40:06 UTC Comment hidden (obsolete)
Comment 59 Julian Maurice 2016-09-06 10:40:10 UTC Comment hidden (obsolete)
Comment 60 Julian Maurice 2016-09-06 10:40:15 UTC Comment hidden (obsolete)
Comment 61 Julian Maurice 2016-09-06 10:40:19 UTC Comment hidden (obsolete)
Comment 62 Julian Maurice 2016-09-06 10:40:23 UTC Comment hidden (obsolete)
Comment 63 Julian Maurice 2016-09-06 10:40:27 UTC Comment hidden (obsolete)
Comment 64 Julian Maurice 2016-09-06 10:40:31 UTC Comment hidden (obsolete)
Comment 65 Julian Maurice 2016-09-06 10:40:36 UTC Comment hidden (obsolete)
Comment 66 Julian Maurice 2016-09-06 10:40:40 UTC Comment hidden (obsolete)
Comment 67 Julian Maurice 2016-09-06 10:47:13 UTC
There is a lot of patches there, it makes the rebase process tedious.
Since they are all from the same author (and many are simple fixes), I think it's time to squash them all!
Comment 68 Julian Maurice 2016-09-06 10:56:38 UTC
Created attachment 55245 [details] [review]
Bug 13371: Add filters on the supplier list view

This patch adds the ability to filter the basket list depending on its
creator name, basketgroup name, dates (creation, close), etc.
It also adds a new link to filter on opened baskets only and the ability
to switch to a simple view if the complete view is to complex

Test plan:
Go on the supplier list view (acqui/booksellers.pl) and confirm that the
view is more ergonomic and the filters permit to the librarians to find
a basket more easily than before.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>
Comment 69 Julian Maurice 2016-09-06 11:02:10 UTC
Paola, you did not sign off all the patches but I left the Signed-off-by line in the squashed commit message. Tell me if you want it to be removed.
The simple view still needs to be tested.
Comment 70 Marc Véron 2016-10-03 14:57:21 UTC
Created attachment 55978 [details] [review]
Bug 13371: Add filters on the supplier list view

This patch adds the ability to filter the basket list depending on its
creator name, basketgroup name, dates (creation, close), etc.
It also adds a new link to filter on opened baskets only and the ability
to switch to a simple view if the complete view is to complex

Test plan:
Go on the supplier list view (acqui/booksellers.pl) and confirm that the
view is more ergonomic and the filters permit to the librarians to find
a basket more easily than before.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Comment 71 Marcel de Rooy 2016-11-25 08:57:44 UTC
This is a hard one for QA imo.
We need some feedback from people actually working with acquisitions here, or interface design experts. Do they view this as an improvement?

Some of the filters for instance basket number or date seem to be handy.
The vendor name is not as prominently visible as it was. Improve?
I did not test with much data. Seems to be no paging? Filter on date will make it easier.
The distinction between simple and complete view makes not much sense to me. I read the request for it. But this view is so 'simple' that I am not sure if it is of real use. Note that you cannot change between both if you found only one vendor. Would storing the filter values in the cookie be helpful? Not sure..
Should you toggle between "Show active and inactive baskets | Show opened baskets only" instead of showing both?
Comment 72 Koha Team University Lyon 3 2016-12-16 16:52:51 UTC
Hi,
I haven't really tested the filters, but something bothers me in this bug.
When we click on a vendor, by default, I can't see any baskets...
It would be great if we could keep the current behaviour : see by default all the active baskets.

I'm sorry, I couldn't test it more consistently for a while.

Sonia
Comment 73 Josef Moravec 2017-01-18 11:57:16 UTC
This will need to adapt for recently pushed bug 16239,

See https://wiki.koha-community.org/wiki/Interface_patterns
especially buttons and modals section.
Comment 74 Julian Maurice 2017-01-20 09:42:47 UTC
Created attachment 59312 [details] [review]
Bug 13371: Add filters on the supplier list view

This patch adds the ability to filter the basket list depending on its
creator name, basketgroup name, dates (creation, close), etc.
It also adds a new link to filter on opened baskets only and the ability
to switch to a simple view if the complete view is to complex

Test plan:
Go on the supplier list view (acqui/booksellers.pl) and confirm that the
view is more ergonomic and the filters permit to the librarians to find
a basket more easily than before.

Signed-off-by: Paola Rossi <paola.rossi@cineca.it>

Followed test plan, works as expected.
Signed-off-by: Marc Véron <veron@veron.ch>
Comment 75 Julian Maurice 2017-01-20 09:43:11 UTC
Patch rebased on master
Comment 76 Marcel de Rooy 2017-03-10 09:52:04 UTC
Jonathan or Julian:
Could you try to get some more feedback on this bug in view of earlier comments (for example 71 and 72) ? Mailing list, IRC, etc. ?
Without some more positive feedback, this patch gets stuck here..
Comment 77 Marcel de Rooy 2017-03-31 09:54:29 UTC
Changing status to reflect need for feedback (see former comment)
Comment 78 Katrin Fischer 2017-08-17 10:40:59 UTC
CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/acqui/booksellers.tt

I'd like to take a look, but patches no longer apply. Can you please rebase?