[Koha-bugs] [Bug 32447] In items table barcode column can not be filtered

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32447

--- Comment #8 from Andreas Roussos <a.roussos at dataly.gr> ---
Apparently, there's just one more case where a DataTable (DT)
can be filtered with search <input>s and that takes place in
reports/itemslost.pl (Reports > Lost items > Results):

$ git grep --name-only table_filters.js -- ':!*.po'
koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt
koha-tmpl/intranet-tmpl/prog/en/modules/reports/itemslost.tt

Because the lost items results page is structured differently
compared to the bibliographic record details page (for example
the header cells don't have ids or data-colname attributes),
the patch mentioned earlier inadvertently breaks the 'Activate
filters' link with the following message logged in the console:

Uncaught Error: Syntax error, unrecognized expression: tr.columnFilter # input

I actually managed to fix that and got the link to work either
by manually adding unique ids to the <th> elements _or_ by
changing the related jQuery selector in my patch to not depend
on the cell id (the latter is probably a better idea until we
sort out the template file in question on a separate bug).

Then, clicking on 'Activate filters' worked but I run into
a different issue: the <input> elements were not being created
by the columnFilter DT plugin. To fix that, I temporarily
modified the function bound to the 'Activate filters' button's
click() event so that it always passes bRedrawFilters == true
when calling activate_filters(), effectively redrawing the DT
filters every time their visibility (not to be confused with
column visibility!) is toggled.

Now the <input>s appeared and search was working properly
save for the erratic behaviour whenever you toggled a column
(outlined in Bug 32448).

To fix that I added the necessary columnsInit() function to
koha-tmpl/intranet-tmpl/prog/en/modules/reports/itemslost.tt
and reverted the temporary change I made above so that it
would now pass bRedrawFilters == false (which had to be the
optimal solution as you should't have to redraw when you just
want to display, right?)

There was a glitch, though: unless I toggled the visibility
of at least one column *before* activating the DT filters,
the DT filters would not render when I clicked on the
'Activate filters' button. And here's why:

In my patch I take advantage of the already existing code
in koha-tmpl/intranet-tmpl/prog/en/includes/columns_settings.inc
that attaches an event handler function to the DataTables
column-visibility.dt event, which in turn calls columnsInit()
(should that function be defined elsewhere):

213     table.dataTable(new_parameters);
214     table.DataTable().on("column-visibility.dt", function(){
215         if( typeof columnsInit == 'function' ){
216             // This function can be created separately and used to trigger
217             // an event after the DataTable has loaded AND column
visibility
218             // has been updated according to the table's configuration
219             columnsInit();
220         }
221     }).columns( hidden_ids ).visible( false );

The only modification I made to the above code was to change
the columnsInit() call to also pass on the DT table object:

219             columnsInit(this);

To make this work I also added the following code in
koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/detail.tt:

1969         function columnsInit(table) {
1970             activate_filters(table.id, false, true);
1971         }

That way, whenever a table column is added to/removed from the
table via the "⚙ Columns" button, the DT filters are redrawn
and their search boxes work just fine.

There's a crucial point to be made, however, which is this:

Because the 'Lost items' results DT currently has no hidden
columns (per the admin/columns_settings.yml column settings),
the column-visibility.dt event does _not_ fire upon page load
to trigger the initial render of the table filters.

To avoid this, the simple-yet-not-optimal solution is to
simply call activate_filters() with bRedrawFilters == true
all the time!

-- 
You are receiving this mail because:
You are watching all bug changes.