[Bug 38196] New: Filter out concerns by specific status does not include concern without status
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug ID: 38196 Summary: Filter out concerns by specific status does not include concern without status Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: jonathan.druart@gmail.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl Depends on: 35628 You can filter out concerns by status (ie. linked with TICKET_STATUS AV). But if you use this "Filter" link on top of the page to remove the concerns with this specific status, it will also remove the concerns without a specific status. concern 1 | Open concern 2 | Resolved concern 3 | status_1 concern 4 | status_2 "Filter status_1" should remove concern 3 only. However it will only show concern 4. This is because the query is ([-and => {status => { '!=' => "status_1" }}]) And does not include status that are NULL in DB. use Koha::Tickets; my $t = Koha::Tickets->search; say $_->status // "undefined" for $t->as_list; say "==="; $t = Koha::Tickets->search([-and => {status => { '!=' => "status_1" }}]); say $_->status for $t->as_list; undefined undefined status_1 status_2 === status_2 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add optional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #1 from Jonathan Druart <jonathan.druart@gmail.com> --- I could fix but only on top of bug 33484 (to prevent conflicts). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bibliothek@th-wildau.de Assignee|koha-bugs@lists.koha-commun |bibliothek@th-wildau.de |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |42283 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42283 [Bug 42283] Tidy all script tags - cataloguing -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Trivial patch Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #2 from Jan Kissig <bibliothek@th-wildau.de> --- Created attachment 199411 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199411&action=edit Bug 38196: Fix filter in catalog concerns to show tickets where status is NULL This patch fixes issues on catalog concerns when filtering for self defined authorized values (AV). When querying for status != AV, also rows with status = NULL are omitted as SQL here only checks for defined values in status. The patch wraps the a filter query with an 'or status is NULL'. Test plan: apply patch dependencies (42283) if not already included and run restart_all a) enable system preference CatalogConcerns b) create some authorised values in TICKET_STATUS c) create several concerns/tickets (biblio detail page -> new catalog concern) d) go to /cgi-bin/koha/cataloguing/concerns.pl and change some ticket status to have some variation for filtering e) play with the filters on the top (resolved and self created TICKET_STATUS) - when clicking 'Filter resolved' tickets with status 'Resolved by ... date' get filtered - when filtering self created TICKET_STATUS values tickets with that status AND tickets with status Open are disappearing f) apply patch and run restart_all g) retry steps in e) and check that only the filtered status are filtered from the results list. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Bug 38196 depends on bug 42283, which changed state. Bug 42283 Summary: Tidy all script tags - cataloguing https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42283 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #3 from David Nind <david@davidnind.com> --- The patch still applies. Could you clarify what is not working? I can't reproduce the issue described. This is because the 'custom' filters at the top of the page (under the heading Catalog concerns) are not working - they do nothing when you click on them (for me). Maybe this is another bug that has crept in since your patch was added? What I did: 1. Created 4 authorized values for TICKET_STATUS: - Option 1 - Option 2 - Option 3 - Option 4 2. Created some catalog concerns (six in total). 3. For four catalog concerns, I changed the status to a mix of the options, resolved one, and left one open. 4. The "Filter resolved" filter worked as expected: - Filter resolved: 5 listed (only 1 resolved and this is not shown) - Include resolved: 6 listed 5. None of the custom filters (Filter Option 1, Filter Option 2, Filter Option 3, Filter Option 4) worked, and there were no errors or messages in the browser console. By not worked, I mean: - Clicking on any of the filters added to the authorized value category did nothing 6. After the patch, no change in behavour. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #4 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Nind from comment #3)
The patch still applies.
Could you clarify what is not working? I can't reproduce the issue described.
This is because the 'custom' filters at the top of the page (under the heading Catalog concerns) are not working - they do nothing when you click on them (for me).
Maybe this is another bug that has crept in since your patch was added?
What I did: 1. Created 4 authorized values for TICKET_STATUS: - Option 1 - Option 2 - Option 3 - Option 4 2. Created some catalog concerns (six in total). 3. For four catalog concerns, I changed the status to a mix of the options, resolved one, and left one open. 4. The "Filter resolved" filter worked as expected: - Filter resolved: 5 listed (only 1 resolved and this is not shown) - Include resolved: 6 listed 5. None of the custom filters (Filter Option 1, Filter Option 2, Filter Option 3, Filter Option 4) worked, and there were no errors or messages in the browser console. By not worked, I mean: - Clicking on any of the filters added to the authorized value category did nothing 6. After the patch, no change in behavour.
Hey David thank you for testing this. Are the TICKET_STATUS AVs named like 'Option 1' or 'Option1'. I just found that having a white space in an AV the filters don't work. Maybe this already solves the problem for testing. As AVs may contain spaces (more than 50 in the db contain one), I have to fix that patch to make these working too. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #5 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to Jan Kissig from comment #4) ...
Hey David thank you for testing this. Are the TICKET_STATUS AVs named like 'Option 1' or 'Option1'. I just found that having a white space in an AV the filters don't work. Maybe this already solves the problem for testing. As AVs may contain spaces (more than 50 in the db contain one), I have to fix that patch to make these working too.
In the manual I found this: "Authorized value is limited to 80 characters and cannot have spaces or special characters other than underscores and hyphens in it." As there are existing AVs with spaces and there is no warning when entering AVs with spaces this contradicts the manual. Maybe this could be discussed further on Mattermost. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #6 from David Nind <david@davidnind.com> --- (In reply to Jan Kissig from comment #4)
Hey David thank you for testing this. Are the TICKET_STATUS AVs named like 'Option 1' or 'Option1'. I just found that having a white space in an AV the filters don't work. Maybe this already solves the problem for testing. As AVs may contain spaces (more than 50 in the db contain one), I have to fix that patch to make these working too.
I can confirm that I had spaces in the authorised values. I retested without spaces in the "Authorized value" field value (and with and without your patch), so OPTION1, OPTION2, OPTION3, and OPTION4, (description fields are "Option X" and so on), I get quite "weird" results. Created six catalog concerns: - Concern 1: Open (no status assigned) - Concern 2: Resolved - Concern 3: OPTION2 (Option 2) - Concern 4: OPTION3 (Option 3) - Concern 5: OPTION2 (Option 2) - Concern 6: OPTION1 (Option 1) What I expected: 1. Going to the page the first time: all catalog concerns are shown (open, different statuses, resolved) 2. Clicking on "Filter resolved": any resolved catalog concerns are not shown (maybe the label should be "Filter out resolved [concerns]") 3. Clicking on "Include resolved": all catalog concerns are shown again 4. Clicking on any of the "Filter XXXX" filters: only shows the catalog concerns with that status What I see with the patches: - 1 to 3 above: works as expected - 4: get "weird" results - I expected clicking on the filter would show only those with that status, instead: . Filter Option 1 (OPTION1): clicking filters out the catalog concern with "Option 1" as the status, includes resolved (5 concerns listed) + Include Option 1: shows all catalog concerns (6) . Filter Option 2 (OPTION2): clicking filters out the 2 catalog concern with "Option 2" as the status, includes resolved (4 concerns listed) + Include Option 2: shows all catalog concerns (6) . Filter Option 3 (OPTION3): clicking filters out the catalog concern with "Option 3" as the status, includes resolved (5 concerns listed) + Include Option 3: shows all catalog concerns (6) . Filter Option 4 (OPTION4): clicking shows no change, as there are no catalog concerns with "Option 4" as the status, includes resolved (6 concerns listed) + Include Option 4: shows all catalog concerns (6) From someone new to this area, I would expect clicking on the filters for the different statuses to only show the catalog concerns that match that status. It seems totally unintuitive to me the way that it is now. Outside the scope of this bug, but this seems a totally different user interface design than used elsewhere. A common model is using tabs with the different status, rather than filters. So, I'm not sure where to go from here.... 1. I think how it is shown now (both before and after the patch) is not what a "normal" staff member would expect: filter/only show catalog concerns that match this status (rather than filtering them out!) 2. Your bug does what it says it will (now including resolved concerns in the list), that is, shows all catalog concerns excluding the status shown in the filter name 3. I don't work in a library, so not sure what the workflow would be for managing concerns -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #7 from David Nind <david@davidnind.com> --- (In reply to Jan Kissig from comment #5)
(In reply to Jan Kissig from comment #4) ...
Hey David thank you for testing this. Are the TICKET_STATUS AVs named like 'Option 1' or 'Option1'. I just found that having a white space in an AV the filters don't work. Maybe this already solves the problem for testing. As AVs may contain spaces (more than 50 in the db contain one), I have to fix that patch to make these working too.
In the manual I found this: "Authorized value is limited to 80 characters and cannot have spaces or special characters other than underscores and hyphens in it."
As there are existing AVs with spaces and there is no warning when entering AVs with spaces this contradicts the manual. Maybe this could be discussed further on Mattermost.
I think this is a "bug": if this is the case, then you shouldn't be able to add and authorized value with a space in it. You should get a form validation error, and ideally it should have a hint that says this. Fixing up existing authorized values that don't meet the criteria could be a challenge... So a separate bug for this I think, if one doesn't exist already. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #8 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Nind from comment #6)
(In reply to Jan Kissig from comment #4)
Hey David thank you for testing this. Are the TICKET_STATUS AVs named like 'Option 1' or 'Option1'. I just found that having a white space in an AV the filters don't work. Maybe this already solves the problem for testing. As AVs may contain spaces (more than 50 in the db contain one), I have to fix that patch to make these working too.
I can confirm that I had spaces in the authorised values.
I retested without spaces in the "Authorized value" field value (and with and without your patch), so OPTION1, OPTION2, OPTION3, and OPTION4, (description fields are "Option X" and so on), I get quite "weird" results.
Created six catalog concerns: - Concern 1: Open (no status assigned) - Concern 2: Resolved - Concern 3: OPTION2 (Option 2) - Concern 4: OPTION3 (Option 3) - Concern 5: OPTION2 (Option 2) - Concern 6: OPTION1 (Option 1)
What I expected: 1. Going to the page the first time: all catalog concerns are shown (open, different statuses, resolved) 2. Clicking on "Filter resolved": any resolved catalog concerns are not shown (maybe the label should be "Filter out resolved [concerns]") 3. Clicking on "Include resolved": all catalog concerns are shown again 4. Clicking on any of the "Filter XXXX" filters: only shows the catalog concerns with that status
What I see with the patches: - 1 to 3 above: works as expected - 4: get "weird" results - I expected clicking on the filter would show only those with that status, instead: . Filter Option 1 (OPTION1): clicking filters out the catalog concern with "Option 1" as the status, includes resolved (5 concerns listed) + Include Option 1: shows all catalog concerns (6) . Filter Option 2 (OPTION2): clicking filters out the 2 catalog concern with "Option 2" as the status, includes resolved (4 concerns listed) + Include Option 2: shows all catalog concerns (6) . Filter Option 3 (OPTION3): clicking filters out the catalog concern with "Option 3" as the status, includes resolved (5 concerns listed) + Include Option 3: shows all catalog concerns (6) . Filter Option 4 (OPTION4): clicking shows no change, as there are no catalog concerns with "Option 4" as the status, includes resolved (6 concerns listed) + Include Option 4: shows all catalog concerns (6)
From someone new to this area, I would expect clicking on the filters for the different statuses to only show the catalog concerns that match that status.
It seems totally unintuitive to me the way that it is now.
Outside the scope of this bug, but this seems a totally different user interface design than used elsewhere. A common model is using tabs with the different status, rather than filters.
So, I'm not sure where to go from here.... 1. I think how it is shown now (both before and after the patch) is not what a "normal" staff member would expect: filter/only show catalog concerns that match this status (rather than filtering them out!) 2. Your bug does what it says it will (now including resolved concerns in the list), that is, shows all catalog concerns excluding the status shown in the filter name 3. I don't work in a library, so not sure what the workflow would be for managing concerns
You are right, the behavior of these filters is somehow opposing how filters are used elsewhere in Koha. Instead of naming it "Filter ..." it should be named "Hide ..." and then the behavior would make much more sense. As the opposing option to "Filter" is "Include", it seems that the intention of the creator of that feature was that it works like it is now. That means Filter will filter out the value that was clicked. Without the patch f.e. filtering for OPTION3 removed OPTION3 and (the bug) also resolved and opened tickets. And this gets fixed by the patch. Also Joubus bug description draws in that direction. Would you think it is sufficient to rename "Filter" to "Hide" for all Buttons above the table? A complete rewrite to change the behavior to a more intuitive pattern could be done in a separate bug then. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #9 from David Nind <david@davidnind.com> --- (In reply to Jan Kissig from comment #8)
And this gets fixed by the patch. Also Joubus bug description draws in that direction. Would you think it is sufficient to rename "Filter" to "Hide" for all Buttons above the table? A complete rewrite to change the behavior to a more intuitive pattern could be done in a separate bug then.
I like changing it to "Hide ..." - reflects what you are actually doing. Then dealing with how it should actually work on another bug. David -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #10 from Jan Kissig <bibliothek@th-wildau.de> --- Created attachment 202339 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202339&action=edit Bug 38196: (follow-up) Rename Filter to Hide in concerns.tt This changes the filter names in concerns.tt from "Filter ..." to "Hide ..." to clarify that a filter here will remove items with that value from the table. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199411|0 |1 is obsolete| | Attachment #202339|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #11 from David Nind <david@davidnind.com> --- Created attachment 202442 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202442&action=edit Bug 38196: Fix filter in catalog concerns to show tickets where status is NULL This patch fixes issues on catalog concerns when filtering for self defined authorized values (AV). When querying for status != AV, also rows with status = NULL are omitted as SQL here only checks for defined values in status. The patch wraps the a filter query with an 'or status is NULL'. Test plan: apply patch dependencies (42283) if not already included and run restart_all a) enable system preference CatalogConcerns b) create some authorised values in TICKET_STATUS c) create several concerns/tickets (biblio detail page -> new catalog concern) d) go to /cgi-bin/koha/cataloguing/concerns.pl and change some ticket status to have some variation for filtering e) play with the filters on the top (resolved and self created TICKET_STATUS) - when clicking 'Filter resolved' tickets with status 'Resolved by ... date' get filtered - when filtering self created TICKET_STATUS values tickets with that status AND tickets with status Open are disappearing f) apply patch and run restart_all g) retry steps in e) and check that only the filtered status are filtered from the results list. Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #12 from David Nind <david@davidnind.com> --- Created attachment 202443 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202443&action=edit Bug 38196: (follow-up) Rename Filter to Hide in concerns.tt This changes the filter names in concerns.tt from "Filter ..." to "Hide ..." to clarify that a filter here will remove items with that value from the table. Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This fixes the filters on release notes| |the staff interface catalog | |concerns page so that it | |now "works as expected" | |(Cataloging > Reports > | |Catalog concerns, or | |"Cataloging concerns | |pending: X" on the staff | |interface home page). | | | |Before this fix, the | |filters weren't including | |concerns with no status | |assigned. | | | |How the filters now work: | | | |1. There is a "Hide | |resolved" (default) filter | |(with "Include resolved" as | |its inverse). When first | |accessing the catalog | |concerns page, all catalog | |concerns are shown: | | - clicking "Hide | |resolved": | | - Hides resolved | |concerns | | - Shows all other | |concerns, including those | |with no status assigned | | - clicking the inverse | |"Include resolved" shows | |all concerns regardless of | |status | | - the label was changed | |from "Filter resolved" to | |"Hide resolved" | | | |2. There are also filters | |for all the status codes | |defined using the | |TICKET_STATUS authorized | |value category: | | - the filters are now | |labelled "Hide [status | |description]" (the inverse | |is "Include [status | |description]"), instead of | |"Filter [status | |description]" | | - clicking the filter | |for a status hides the | |concerns with that status | | - to show all the | |concerns, click "Include | |[status description]" | | | |The renaming should make it | |clearer what the filters | |do. | | | |A separate bug also was | |created to look at options | |to make the filters work | |similar to other filters in | |other areas, as the | |behavour on the catalog | |concerns page is quite | |different from filters used | |elsewhere in Koha. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |blawlor@clamsnet.org |y.org | CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA --- Comment #13 from Brendan Lawlor <blawlor@clamsnet.org> --- There is a bug in concerns.tt line 93 when looping over the checked checkboxes: let av = el.id.split("_")[1]; This takes the checkbox id, splits on "_" and takes the second element, which should be the authorized value for the filter to use. But in line 43 the checkbox ids are rendered like this: id="hide_[% st.authorised_value | html %]" If you create an authorized value with an underscore like IN_PROGRESS the checkbox id will be hide_IN_PROGRESS. Then splitting on '_' and taking the second element makes av = 'IN' and the filter will be { "!=": "IN" } which doesn't match, or could even match a different authorized value. Instead of trying to get the authorized values of the statuses from the checkbox ids, it'd be cleaner to use the statuses array that is already built in lines 71-77: var statuses = []; [% FOR st IN status %] statuses.push({ authorised_value: "[% st.authorised_value | html %]", lib: "[% st.lib | html %]", }); [% END %] Then at line 90 you could loop over the statuses and check if the checkbox is checked like this: status: function () { let avfilters = ["-and"]; statuses.forEach(s => { if ($(`#hide_${s.authorised_value}`).is(":checked")) { avfilters.push({ "!=": s.authorised_value }); } }); -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38196 --- Comment #14 from Brendan Lawlor <blawlor@clamsnet.org> --- One other small thing is the filter and bars icons are odd in this case. I think changing the wording to Show and Hide and using fa-eye and fa-eye-slash icons might be more intuitive. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org