Allows to choose columns to display on items table in the MARCdetail page (cgi-bin/koha/catalogue/MARCdetail.pl). Also, the columns displayed are saved for each users in database.
Created attachment 53226 [details] [review] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Also, the columns displayed are saved for each users in database. Test plan: - apply this BZ, - launch perl installer/data/mysql/updatedatabase.pl - launch perl misc/devel/update_dbix_class_files.pl - go to the items tab on cgi-bin/koha/catalogue/MARCdetail.pl page you should be able to hide/show each columns. - leave this page and come back with the same koha account: You should have the same columns shown/hidden as when you left.
Created attachment 53303 [details] [review] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Also, the columns displayed are saved for each users in database. Test plan: - apply this BZ, - launch perl installer/data/mysql/updatedatabase.pl - launch perl misc/devel/update_dbix_class_files.pl - go to the items tab on cgi-bin/koha/catalogue/MARCdetail.pl page you should be able to hide/show each columns. - leave this page and come back with the same koha account: You should have the same columns shown/hidden as when you left.
i have thise message in the sandbox One http://pro.test1.biblibre.com/cgi-bin/koha/catalogue/MARCdetail.pl?biblionumber=1 Template process failed: undef error - DBIx::Class::Schema::resultset(): Can't find source for UsersColumnsSetting at /home/koha/src/C4/Utils/DataTables/DynamicColumnsSettings.pm line 23 For help, please send mail to the webmaster (webmaster@matrice-koha36-sandbox), giving this error message and the time and date of the error.
with the updatedatabse it's work
Created attachment 53510 [details] [review] [SIGNED-OFF] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Also, the columns displayed are saved for each users in database. Test plan: - apply this BZ, - launch perl installer/data/mysql/updatedatabase.pl - launch perl misc/devel/update_dbix_class_files.pl - go to the items tab on cgi-bin/koha/catalogue/MARCdetail.pl page you should be able to hide/show each columns. - leave this page and come back with the same koha account: You should have the same columns shown/hidden as when you left. Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Alex, I wanted to implement this feature for a while, but I don't understand the way you chose :) Why did not you store the value in the browser session? You are adding a new behavior but only for 1 table, it would be good to have it everywhere the columns settings are used.
Hm, I have to say that I like the idea of storing the chosen options permanently. This seems to reflect what people expect here considering the feedback from training libraries.
I really like this feature and agree with Cait, the ability for users to save their settings will make workflows easier for librarians I agree with Jonathan too, this feature should be made usable for other pages too, even if it is only introduced here first. 1 - C4/Utils/DataTables/DynamicColumnsSettings.pm - sub catalogue_marcdetail_itemst This should be more generic, the work should be done in a function that can be passed data from any page 2 - The script should be moved ot a javascript files for inclusion when necessary, and can then be triggered by code on each page. 3 -The current code calls the service function each time the table is rendered, so a sort will also make a call, this should only happen when column view changes 4 - Ideally when a user restores all columns we shouldn't need to save their data, maybe we only store columns that are exceptions? 5 - This should use the REST api and not an svc script 6 - $schema->resultset('UsersColumnsSetting')->update_or_create This should use Koha::Object
Created attachment 59566 [details] [review] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Also, the columns displayed are saved for each users in database. Test plan: - apply this BZ, - launch perl installer/data/mysql/updatedatabase.pl - launch perl misc/devel/update_dbix_class_files.pl - go to the items tab on cgi-bin/koha/catalogue/MARCdetail.pl page you should be able to hide/show each columns. - leave this page and come back with the same koha account: You should have the same columns shown/hidden as when you left.
Created attachment 59567 [details] [review] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Also, the columns displayed are saved for each users in database. Test plan: - apply this BZ, - launch perl installer/data/mysql/updatedatabase.pl - launch perl misc/devel/update_dbix_class_files.pl - go to the items tab on cgi-bin/koha/catalogue/MARCdetail.pl page you should be able to hide/show each columns. - leave this page and come back with the same koha account: You should have the same columns shown/hidden as when you left.
Here is a replacement patch. Code is more generic, svc script is replaced with a new REST api method and UsersColumnsSetting has its Koha objects. I change the javascript code to make other tables can use this feature with few changes. It could have been more usable but this means i should have to modify the KohaTable call for all these tables.
(In reply to Nick Clemens from comment #8) > I really like this feature and agree with Cait, the ability for users to > save their settings will make workflows easier for librarians > > I agree with Jonathan too, this feature should be made usable for other > pages too, even if it is only introduced here first. > > 1 - C4/Utils/DataTables/DynamicColumnsSettings.pm - sub > catalogue_marcdetail_itemst > This should be more generic, the work should be done in a function that can > be passed data from any page I don't know how to make it more generic. It return all item fields depending on a framwork code... > > 2 - The script should be moved ot a javascript files for inclusion when > necessary, and can then be triggered by code on each page. > > 3 -The current code calls the service function each time the table is > rendered, so a sort will also make a call, this should only happen when > column view changes What do you mean by service function ? If you speak about the saveStateCallback, it is called only when a "column button" is clicked. > > 4 - Ideally when a user restores all columns we shouldn't need to save their > data, maybe we only store columns that are exceptions? There is no option for restoring all columns for now. > > 5 - This should use the REST api and not an svc script > > 6 - $schema->resultset('UsersColumnsSetting')->update_or_create > This should use Koha::Object
Taking a closer look this is really interesting as it's allowing to store the column definitions by user. Can you please rebase? 59567 - Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Using index info to reconstruct a base tree... M api/v1/swagger/definitions.json M api/v1/swagger/paths.json M catalogue/MARCdetail.pl M installer/data/mysql/kohastructure.sql M koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/MARCdetail.tt Falling back to patching base and 3-way merge... Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/MARCdetail.tt CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/catalogue/MARCdetail.tt Auto-merging installer/data/mysql/kohastructure.sql Auto-merging catalogue/MARCdetail.pl Auto-merging api/v1/swagger/paths.json Auto-merging api/v1/swagger/definitions.json CONFLICT (content): Merge conflict in api/v1/swagger/definitions.json error: Failed to merge in the changes. Patch failed at 0001 Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem run "git bz apply --continue". If you would prefer to skip this patch, instead run "git bz apply --skip". To restore the original branch and stop patching run "git bz apply --abort". Patch left in /tmp/Bug-16881---Apply-KohaTable-and-ColVis-plugin-on-M-0QlVGC.patch sloth:/usr/local/vagrant/kohaclone_master (58-16881-colvis|AM 1/1) $ git status On branch 58-16881-colvis You are in the middle of an am session. (fix conflicts and then run "git am --continue") (use "git am --skip" to skip this patch) (use "git am --abort" to restore the original branch)
Would this include allowing users to change the order in which the columns display? i.e. callnumber followed by enumeration followed by barcode, etc...
(In reply to Joy Nelson from comment #14) > Would this include allowing users to change the order in which the columns > display? No, it only allows for the showing or hiding columns in place.
Created attachment 79107 [details] [review] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table Also, the columns displayed are saved for each users in database. Test plan: - apply this BZ, - launch perl installer/data/mysql/updatedatabase.pl - launch perl misc/devel/update_dbix_class_files.pl - go to the items tab on cgi-bin/koha/catalogue/MARCdetail.pl page you should be able to hide/show each columns. - leave this page and come back with the same koha account: You should have the same columns shown/hidden as when you left. Rebased-by: Alex Arnaud <alex.arnaud@biblibre.com> (2018-09-19)
Created attachment 79108 [details] [review] Bug 16881: update schema file
After testing hiding and showing columns, I see entries in users_columns_settings for my account, but is_hidden is 0 even if I have selected columns to be hidden.
I can't reproduce that. Hiding a column set is_hidden to 1 and vice versa. I may miss a specific use case. Can you tell me exactly what you did? As you've probably noticed, we don't store the column name in database but the corresponding mapped subfield. Are you checking the right one? Also, changes are done using an asynchronous call to the API. This may take some time depending on your local instance/hardware.
H Alex, I wanted to see if I can replicate Owen's problem, but the patches on longer apply :( One thing I'd like to make sure is that user configured upper case subfields (mapped to more_subfields_xml) still can be shown - it's about the only place they do show at the moment.
This bug seems to partially reproduce bug 22276 which was closed fixed (at least the "column setting store per user" feature).
*** This bug has been marked as a duplicate of bug 33484 ***