Summary: | Staff interface tables with filters - date format needs to be YYYY-MM-DD, need to use authorized value codes or coded values (can't use descriptions) | ||
---|---|---|---|
Product: | Koha | Reporter: | David Nind <david> |
Component: | Staff interface | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | major | ||
Priority: | P5 - low | CC: | anni.maki-mantila, gmcharlt, jonathan.druart |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38108 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39011 |
||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 38071 | ||
Bug Blocks: |
Description
David Nind
2024-10-07 20:20:26 UTC
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. Just updated the title - searching the holdings table using authorized values or coded values is now fixed/will be fixed by bug 38130 and bug 39011. (In reply to David Nind from comment #9) > Just updated the title - searching the holdings table using authorized > values or coded values is now fixed/will be fixed by bug 38130 and bug 39011. Well, not really. I think there are other coded values displayed (mainly those linked to proper authorized values): location, lost, not for loan, etc. (In reply to Jonathan Druart from comment #10) > (In reply to David Nind from comment #9) > > Just updated the title - searching the holdings table using authorized > > values or coded values is now fixed/will be fixed by bug 38130 and bug 39011. > > Well, not really. I think there are other coded values displayed (mainly > those linked to proper authorized values): location, lost, not for loan, etc. My bad, have added back into the title. *** Bug 37875 has been marked as a duplicate of this bug. *** |