When using filters on tables in the staff interface (for both "Search: ______ x Clear filter" and with "Show filters"): 1. Date fields: you need to enter the date in YYYY-MM-DD format, not the way it is displayed in the table 2. Fields using authorized values: you need to enter the code, rather than the description To replicate: 1. Go to a record in the staff interface with multiple items (for example record 146, The definitive guide to Catalyst : writing extensible, scalable, and maintainable Perl-based Web applications <staffinterfaceurl>/cgi-bin/koha/catalogue/detail.pl?biblionumber=146). 2. In the holdings table section, click "Show filters". 3. Using the "Search: ______ x Clear filter": 3.1 Enter "Midway" ==> no results 3.2 Enter "MPL" ==> one result 3.3 Enter "09/04" ==> no results 3.4 Enter "2014-09" ==> results Note: Bug 38071 fixes the "Clear filter" that is not working, in the meantime click "Hide filters" and "Show filters" or clear the text in the search box to clear. 4. Using the table column filters: 4.1 Click "Show filters" 4.2 In the "Last seen" column, start typing 09/04 ==> no results 4.2 In the "Last seen" column, start typing 2014-09 ==> no change as it matches data in the column, if you type 2014-09-01 you should get no results 4.3 In the "Collection" column, start typing "Reference" > no change until you get to "Refe", then you get no results as it is looking for the authorized value code 4.4 Note that the Item type, Current library, and Home library columns all use select lists, so you can't type a value in them. 5. Go to Patrons and click the "Search" button. 6. Perform searches similar to steps 3 and 4, and you will get similar results (use the "Date of birth" column for dates and "Library" or "Category" columns for authorized values).
I'm not sure what the appropriate solution is: 1. Add a tooltip to the column names. 2. Make the filters work as you would expect (for both ways: date as displayed and YYYY-MM-DD; authorized value code and description). (If library staff know how to make these work, these should continue to work.) 3. Update the manual if required to point this out (if not covered already).
I think this change is certainly a problem, especially since staff won't be able to tell how each table work and we don't have consistent behavior between API driven and non-API driven tables. It was also nice to be able to search for parts of the date, like the year in some cases, that's why I am not sure if a calendar widget would work well here to help translate the dates, but it might be the best solution UI wise?
Searching on the year is possible and returns the correct results. Searching on the full date (iso or syspref-formatted) is working. Substring of iso is working. What is not working is searching with a substring of the syspref-formatted version.
(In reply to Jonathan Druart from comment #3) > Searching on the year is possible and returns the correct results. > Searching on the full date (iso or syspref-formatted) is working. > Substring of iso is working. > > What is not working is searching with a substring of the syspref-formatted > version. Thanks for clearing this up! In this case it might be OK to have some notes in the manual?
I have opened bug 38130 for the library columns. Item types won't be possible as we have them stored in 2 different columns (you know, this stupid item-level_itypes syspref...) AVs neither, too complicated IMO. I am not sure it's possible. See the commit message of bug 38130.
(In reply to Jonathan Druart from comment #5) > I have opened bug 38130 for the library columns. > > Item types won't be possible as we have them stored in 2 different columns > (you know, this stupid item-level_itypes syspref...) > > AVs neither, too complicated IMO. I am not sure it's possible. > > See the commit message of bug 38130. Can you explain the problem with the itemtypes (maybe on a different bug)? A filter for itemtypes would definitely be needed again. And as we move more tables to API, even more.
What is meant by "need to use authorised value codes" in the bug title? Maybe needs to use date format settings?
(In reply to Katrin Fischer from comment #6) > (In reply to Jonathan Druart from comment #5) > > I have opened bug 38130 for the library columns. > > > > Item types won't be possible as we have them stored in 2 different columns > > (you know, this stupid item-level_itypes syspref...) > > > > AVs neither, too complicated IMO. I am not sure it's possible. > > > > See the commit message of bug 38130. > > Can you explain the problem with the itemtypes (maybe on a different bug)? A > filter for itemtypes would definitely be needed again. And as we move more > tables to API, even more. There is one, use the filter at the top of the column. However it will only work if it is set at the item level. We actually could do the same as what I have on bug 38130 for the library. We are displaying the "effective" item type, so the one at the biblio level if none at the item level. But filtering won't work. Also it won't be possible to make it work if they are translated.