[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #13 from HKS3 Tadeusz Sośnierz --- > Did you try to pass functions to additional_filters? There is no such parameter, but there is a default_filters that later gets assigned to a (local) additional_filters – but that only gets used when building the DBIC query (here: https://gitlab.com/koha-community/Koha/-/blob/main/koha-tmpl/opac-tmpl/bootstrap/js/datatables.js?ref_type=heads#L318), not doing the postprocessing of the HTTP response, which is what I'm after. My goal is to sneak my way into dataFilter (here: https://gitlab.com/koha-community/Koha/-/blob/main/koha-tmpl/opac-tmpl/bootstrap/js/datatables.js?ref_type=heads#L92) which is currently not exposed in kohaTable. Part of the underlying issue, in my opinion, is that kohaTable limits the underlying dataTable rather than extending it. Its `ajax`, for instance, forces a default behaviour on top of user preferences rather than just providing sensible (but extensible) defaults: see the order of arguments in https://gitlab.com/koha-community/Koha/-/blob/main/koha-tmpl/opac-tmpl/bootstrap/js/datatables.js?ref_type=heads#L609 – the default implementation "wins". A kohaTable user cannot provide their own implementation of dataFilter (or data, or beforeSend...), since _dt_default_ajax() always has the last word. Every potential dataTable usage that might be needed in the future (like the ones in this issue) therefore requires additional APIs to be built to expose the functionality that dataTables already provides – and the fact that we have *two* independent kohaTables (opac and intranet) makes this even worse. In (my) ideal world, kohaTable would be a subclass of the dataTable rather than a (leaky) abstraction on top of it – and LSP would then ensure that I have everything I might need :) Some of the customer code I've written before has used dataTables directly (and copying code from kohaTable) for this exact reason – bending and twisting kohaTables just wasn't worth it (this is why my initial patch for https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39600 used dataTables instead of kohaTable). In fancy terms, -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #14 from HKS3 Tadeusz Sośnierz --- (In reply to HKS3 Tadeusz Sośnierz from comment #13) > In fancy terms, (there are no fancy terms, but I have that you can't edit bugzilla comments :F) -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #12 from Jonathan Druart --- Did you try to pass functions to additional_filters? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #11 from HKS3 Tadeusz Sośnierz --- (In reply to Pedro Amorim from comment #10) > (In reply to HKS3 Tadeusz Sośnierz from comment #8) > > > Any ideas for what an elegant and future-proof solution could look like > > here? > > I've provided a patch illustrating my suggestion. With a bit more work it > should satisfy your use case of filtering on 'status', and done at the > datatables.js layer. > The code not being DRY is something that imo should be discussed (and fixed > someday) in bug 35716 as it's a perpetual problem in Koha far exceeding this > particular OPAC ILL table. Ah, I don't think that covers the second case though – introducing a dataFilter-like functionality, where we process the data between the response arriving and the table being rendered. A customer over here is interested in "streamlining" the statuses of requests, so they either show "New", "In progress" or "Completed" without going into further details – dataFilter fills that purpose nicely, and my second patch enables that – and I don't think it's a pattern we use with kohaTables anywhere else so far, neither in opac or intranet. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 Pedro Amorim changed: What|Removed |Added See Also||https://bugs.koha-community ||.org/bugzilla3/show_bug.cgi ||?id=35716 --- Comment #10 from Pedro Amorim --- (In reply to HKS3 Tadeusz Sośnierz from comment #8) > Any ideas for what an elegant and future-proof solution could look like here? I've provided a patch illustrating my suggestion. With a bit more work it should satisfy your use case of filtering on 'status', and done at the datatables.js layer. The code not being DRY is something that imo should be discussed (and fixed someday) in bug 35716 as it's a perpetual problem in Koha far exceeding this particular OPAC ILL table. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #9 from Pedro Amorim --- Created attachment 182947 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182947&action=edit Bug 40013: [ALTERNATIVE WIP] Add 'searchable' option to OPAC table columns This is a WIP of my suggestion. It provides column search inputs for each of the 'searchable': true columns. This provides value to all OPAC tables, as it adds the functionality at the datatables layer. This is a copy paste from the datatables.js in intranet-tmpl, ideally it'd be DRY, but we don't live in an ideal world. More work needs to be done: 1) Clicking on the input sorts the column (it shouldnt) 2) Columns like 'status' ideally would have a dropdown of values, not a text input. 3) Searching on extended_attributes requires additional work so my suggestion for now would be to have 'searchable': false for these cases. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013
--- Comment #8 from HKS3 Tadeusz Sośnierz ---
I'm really not stoked on the "API" of this – manipulating carefully named
globals to alter the behaviour is not something I'm fond of, but it seems to me
like it'd require a massive overhaul to make it better. Ideally I'd see it as
something like `$("#illrequestlist").kohaTable().addDataFiltter(...)` instead,
but we're not really working with fully-fledged objects here that we can add
methods to. There is a precedent like he aforementioned _dt_add_filters, but in
case of dataFilter (see second patch) that quickly gets very awkward, since
those dataFilters are established at _dt_default_ajax time, so not easily
accesible to modify it at a later time.
Any ideas for what an elegant and future-proof solution could look like here?
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #7 from HKS3 Tadeusz Sośnierz --- Created attachment 182945 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182945&action=edit Bug 40013: Allow plugging in custom dataFilters to OPAC kohaTable This allows plugins/opacJS to alter the response data before it's displayed to the user. -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013
HKS3 Tadeusz Sośnierz changed:
What|Removed |Added
Attachment #182813|0 |1
is obsolete||
--- Comment #6 from HKS3 Tadeusz Sośnierz ---
Created attachment 182944
-->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182944&action=edit
Bug 40013: Add a way to inject custom filters for OPAC ILL table
Test plan:
1. In KTD, go to
http://localhost:8081/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=master+switch
and enable the ILL module
2. Set the following OPACUserJS:
document.addEventListener('DOMContentLoaded', function() {
const listInfo = document.querySelector('#illrequestlist_info');
if (listInfo) {
const statusFilters = document.createElement('div');
listInfo.parentElement.appendChild(statusFilters);
const shortcuts = [
['Show new requests', 'NEW'],
['Show ordered requests', 'ORDERED'],
['Show all requests', ''],
];
for (const [label, status] of shortcuts) {
const button = document.createElement('button');
button.textContent = label;
button.className = 'btn btn-secondary';
button.onclick = () => {
if (status) {
opac_illrequests_additional_filters['me.status'] = {
'=': status };
} else {
delete
opac_illrequests_additional_filters['me.status'];
}
$('#illrequestlist').DataTable().draw();
};
statusFilters.parentElement.appendChild(button);
}
}
});
2. Run the following in koha-shell to populate the request list for user
`koha`:
perl -Mt::lib::TestBuilder -e '
my $builder = t::lib::TestBuilder->new;
do {
$builder->build_sample_ill_request({borrowernumber => 51, status => ($_
> 10 ? "NEW" : "ORDERED")});
} for (1..50);
'
3. Navigate to http://localhost:8080/cgi-bin/koha/opac-illrequests.pl, log in
as `koha` as needed
4. Observe the new buttons affecting the requests displayed in the table
Sponsored-by: Wiko
--
You are receiving this mail because:
You are watching all bug changes.
___
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #5 from HKS3 Tadeusz Sośnierz --- Is there a good reason why they're not identical, and/or do not have feature parity? I'm not sure what the historical reasons are, but is there a good reasons why they *shouldn't* be functionally identical? -- You are receiving this mail because: You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 David Nind changed: What|Removed |Added Assignee|[email protected] |[email protected] |ity.org | --- Comment #4 from David Nind --- Added assignee. I changed the status to In Disussion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 David Nind changed: What|Removed |Added CC||[email protected] Status|Needs Signoff |In Discussion -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 --- Comment #3 from Jonathan Druart --- (In reply to Pedro Amorim from comment #2) > This makes sense, but I wonder if we should tackle it differently? > > kohaTable is defined twice, once for Intra, once for OPAC (another example > where bug 35716 would prevent it): > /koha/koha-tmpl/intranet-tmpl/prog/js/datatables.js > /koha/koha-tmpl/opac-tmpl/bootstrap/js/datatables.js > > Intra kohaTable implements _dt_add_filters, OPAC does not. > I suppose it was never implemented for OPAC kohaTable because there was no > need for it, not until now anyway. > > My suggestion here would be to implement _dt_add_filters in the OPAC > kohaTable, adding the possibility of column filters and enabling the REST > API based filtering we're aiming for here. > > This would also enable any future REST driven OPAC table to have searchable > columns. > > I may be completely wrong here, or this can also be considered as a > follow-up. Up for discussion. The two versions of datatables.js are not identical. You could move and centralize most of the code, not everything. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013
--- Comment #1 from HKS3 Tadeusz Sośnierz ---
Created attachment 182813
-->
https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182813&action=edit
Bug 40013: Add a way to inject custom filters for OPAC ILL table
Test plan:
1. In KTD, go to
http://localhost:8081/cgi-bin/koha/admin/preferences.pl?tab=&op=search&searchfield=master+switch
and enable the ILL module
2. Set the following OPACUserJS:
document.addEventListener('DOMContentLoaded', function() {
const listInfo = document.querySelector('#illrequestlist_info');
if (listInfo) {
const statusFilters = document.createElement('div');
listInfo.parentElement.appendChild(statusFilters);
const shortcuts = [
['Show new requests', 'NEW'],
['Show ordered requests', 'ORDERED'],
['Show all requests', ''],
];
for (const [label, status] of shortcuts) {
const button = document.createElement('button');
button.textContent = label;
button.className = 'btn btn-secondary';
button.onclick = () => {
if (status) {
opac_illrequests_additional_filters['me.status'] = {
'=': status };
} else {
delete
opac_illrequests_additional_filters['me.status'];
}
$('#illrequestlist').DataTable().draw();
};
statusFilters.parentElement.appendChild(button);
}
}
});
2. Run the following in koha-shell to populate the request list for user
`koha`:
perl -Mt::lib::TestBuilder -e '
my $builder = t::lib::TestBuilder->new;
do {
$builder->build_sample_ill_request({borrowernumber => 51, status => ($_
> 10 ? "NEW" : "ORDERED")});
} for (1..50);
'
3. Navigate to http://localhost:8080/cgi-bin/koha/opac-illrequests.pl, log in
as `koha` as needed
4. Observe the new buttons affecting the requests displayed in the table
Sponsored-by: Wiko
--
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.
___
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 Pedro Amorim changed: What|Removed |Added CC||[email protected], ||[email protected], ||[email protected] ||o.uk --- Comment #2 from Pedro Amorim --- This makes sense, but I wonder if we should tackle it differently? kohaTable is defined twice, once for Intra, once for OPAC (another example where bug 35716 would prevent it): /koha/koha-tmpl/intranet-tmpl/prog/js/datatables.js /koha/koha-tmpl/opac-tmpl/bootstrap/js/datatables.js Intra kohaTable implements _dt_add_filters, OPAC does not. I suppose it was never implemented for OPAC kohaTable because there was no need for it, not until now anyway. My suggestion here would be to implement _dt_add_filters in the OPAC kohaTable, adding the possibility of column filters and enabling the REST API based filtering we're aiming for here. This would also enable any future REST driven OPAC table to have searchable columns. I may be completely wrong here, or this can also be considered as a follow-up. Up for discussion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
[Koha-bugs] [Bug 40013] Allow custom/plugable filtering options for OPAC ILL table
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 HKS3 Tadeusz Sośnierz changed: What|Removed |Added Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. ___ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
