To reproduce: 1) Create a new patron category, visit: /cgi-bin/koha/admin/categories.pl?op=add_form 2) Add a category code, en enrollment period, a category type and a really long description like: "This is a real long description of the patron category code for demo purposes This is a real long description of the patron category code for demo purposes"" 3) Now do the same but for a library, visit: /cgi-bin/koha/admin/branches.pl?op=add_form 4) Add a library code and a really long name like: "This is a real long library name for demo purposes This is a real long library name for demo purposes" 5) Visit patrons home: /cgi-bin/koha/members/members-home.pl 6) Hit "Search". Notice the "library" and "category" columns grow in width to match the largest option (added in previous steps) 7) Edit a patron, assign that patron the library and category above, go back to the table.
Created attachment 161446 [details] [review] Bug 35908: Add truncateStringForDisplay Test plan: 1) Create a new patron category, visit: /cgi-bin/koha/admin/categories.pl?op=add_form 2) Add a category code, en enrollment period, a category type and a really long description like: "This is a real long description of the patron category code for demo purposes This is a real long description of the patron category code for demo purposes"" 3) Now do the same but for a library, visit: /cgi-bin/koha/admin/branches.pl?op=add_form 4) Add a library code and a really long name like: "This is a real long library name for demo purposes This is a real long library name for demo purposes" 5) Visit patrons home: /cgi-bin/koha/members/members-home.pl 6) Hit "Search". Notice the "library" and "category" columns grow in width to match the largest option (added in previous steps) 7) Edit a patron, assign that patron the library and category above, go back to the table. 8) Repeat 5) and 6). Notice how the table looks 9) Apply patch. Refresh the patron table and notice how it looks.
The patch is a proof of concept that would ideally be extended to all of Koha. Database fields like branchname from table branches are longtext. There is no limit* to what these fields hold, if we display them in the UI directly as they come from the database, we're risking breaking the UI forms in datatables lists, edit forms, etc.
Is this ready for testing (in a sandbox)? There is a test plan and a patch but status is new.
(In reply to Anneli Österman from comment #3) > Is this ready for testing (in a sandbox)? There is a test plan and a patch > but status is new. Hi Anneli, thanks for looking! This is ready for testing, I'm changing it to "In Discussion" as the patch is just a proof of concept, it needs a bit more work (or even maybe a better approach, .e.g REST API instead of a JavaScript approach). The reason I submitted it for now is to have feedback in terms of "does this make sense?", "is this needed?" and only invest in this after that.
The title also could be labeled better. It's not just data being presented in datatables, edit forms also have this form and probably other places as well.
Limiting the length of drop down menu in table would be a good enhancement. If the names are really long it makes the table wider and it doesn't fit in the screen anymore (usability). I tested the patch and it limits the length of drop downs but it also cuts the name of the branch or category and adds dots to imply it continues (Name of the libra...). In the members-home page on the left there is the Search for patron section where the length of the drop down menu is limited but when you open it the name of the branch or category is shown in full. To me it looked a little bit better that way. See attachments (patronsearch.png and patrontable.png). I do not know how these two drop downs differ technically but I like the way Search for patrons section works. When the branch or category is selected for a patron it also cuts the name with dots. Could the name be wrapped to several line instead? See attachment patronselected.png. There are lots of places in Koha where this kind of change would be nice. For instance - in memberentry.pl where you select branch and library for the patron - in moremember.pl where you can add message to patron and the preselected notice is reaaaaally long - in request.pl where table gets really wide if long branch name is selected In moremember.pl and circulation.pl in holds tab and in request.pl for already existing hold, if the long branch name is selected for a hold, the drow down menu is really wide but it shrinks when shorter one is selected. I'm not sure how these menus should work. Maybe just cut it (without dots) so that the table does not get too wide and exits the screen?
(In reply to Anneli Österman from comment #6) > Limiting the length of drop down menu in table would be a good enhancement. > If the names are really long it makes the table wider and it doesn't fit in > the screen anymore (usability). > > I tested the patch and it limits the length of drop downs but it also cuts > the name of the branch or category and adds dots to imply it continues (Name > of the libra...). Yes, this is intentional in this patch. The added dots serve to convey the idea that the text content is longer than what is being displayed. > In the members-home page on the left there is the Search for patron section > where the length of the drop down menu is limited but when you open it the > name of the branch or category is shown in full. To me it looked a little > bit better that way. See attachments (patronsearch.png and patrontable.png). > I do not know how these two drop downs differ technically but I like the way > Search for patrons section works. This is a really good point. I don't see the attachments but having tested myself I know what you're referring to. That technique (fixed width) works well in that particular left filter because the left filter component is of fixed width itself. This is not the case for column headers in the datatables, for example, as pointed out by Jonathan's comment at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34574#c6 The same technique applied there causes the select width to become shorter than its container. This relates to my attempts anyway, others may be more successful than I was. > When the branch or category is selected for a patron it also cuts the name > with dots. Could the name be wrapped to several line instead? See attachment > patronselected.png. Please double-check that your picture attachments have been uploaded, I don't see them here. > There are lots of places in Koha where this kind of change would be nice. > For instance > > - in memberentry.pl where you select branch and library for the patron > - in moremember.pl where you can add message to patron and the preselected > notice is reaaaaally long > - in request.pl where table gets really wide if long branch name is selected > > > In moremember.pl and circulation.pl in holds tab and in request.pl for > already existing hold, if the long branch name is selected for a hold, the > drow down menu is really wide but it shrinks when shorter one is selected. > I'm not sure how these menus should work. Maybe just cut it (without dots) > so that the table does not get too wide and exits the screen? Yes, the issue potentially comes up in many different places, thanks for pointing some of them here. This is exactly what I wanted with this bug, have some discussion about it. My proposed solution currently is shortening the text to something I find reasonable (first 50 characters of the string), but as I said it's just a proof of concept, or others like returning the "shortened" content directly from the API, would potentially fix the problem at its root (content too long) rather than addressing each component's style throughout Koha, but I'm not against any approach.
Created attachment 161529 [details] Long branch name selected to patron Long branch name selected to patron.
Created attachment 161530 [details] Branch name cut Branch name cut
Created attachment 161536 [details] Search for patron drop down menu Search for patron drop down menu
Sorry, I forgot to upload the screenshots. :D Now they are there.