Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table
Summary: Apply KohaTable and ColVis plugin on MARCdetail's items table
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff Client (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Alex Arnaud
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-08 13:52 UTC by Alex Arnaud
Modified: 2021-06-11 11:47 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table (18.17 KB, patch)
2016-07-08 14:06 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table (18.25 KB, patch)
2016-07-12 08:27 UTC, Alex Arnaud
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table (18.35 KB, patch)
2016-07-20 12:59 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table (31.92 KB, patch)
2017-01-26 09:39 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table (31.17 KB, patch)
2017-01-26 09:43 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 16881 - Apply KohaTable and ColVis plugin on MARCdetail's items table (31.46 KB, patch)
2018-09-19 12:58 UTC, Alex Arnaud
Details | Diff | Splinter Review
Bug 16881: update schema file (3.04 KB, patch)
2018-09-19 12:58 UTC, Alex Arnaud
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Arnaud 2016-07-08 13:52:17 UTC
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.
Comment 1 Alex Arnaud 2016-07-08 14:06:25 UTC Comment hidden (obsolete)
Comment 2 Alex Arnaud 2016-07-12 08:27:18 UTC Comment hidden (obsolete)
Comment 3 delaye 2016-07-19 14:11:13 UTC
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.
Comment 4 delaye 2016-07-19 14:42:39 UTC
with the updatedatabse it's work
Comment 5 Owen Leonard 2016-07-20 12:59:45 UTC Comment hidden (obsolete)
Comment 6 Jonathan Druart 2016-07-21 16:39:55 UTC
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.
Comment 7 Katrin Fischer 2016-09-18 23:56:27 UTC
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.
Comment 8 Nick Clemens 2016-10-14 13:02:30 UTC
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
Comment 9 Alex Arnaud 2017-01-26 09:39:09 UTC Comment hidden (obsolete)
Comment 10 Alex Arnaud 2017-01-26 09:43:14 UTC Comment hidden (obsolete)
Comment 11 Alex Arnaud 2017-01-26 09:55:21 UTC
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.
Comment 12 Alex Arnaud 2017-01-26 10:01:08 UTC
(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
Comment 13 Katrin Fischer 2017-10-08 09:56:16 UTC
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)
Comment 14 Joy Nelson 2018-06-07 16:48:55 UTC
Would this include allowing users to change the order in which the columns display?  i.e. callnumber followed by enumeration followed by barcode, etc...
Comment 15 Owen Leonard 2018-06-07 16:59:55 UTC
(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.
Comment 16 Alex Arnaud 2018-09-19 12:58:38 UTC
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)
Comment 17 Alex Arnaud 2018-09-19 12:58:48 UTC
Created attachment 79108 [details] [review]
Bug 16881: update schema file
Comment 18 Owen Leonard 2018-09-19 18:48:07 UTC
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.
Comment 19 Alex Arnaud 2018-09-20 12:17:19 UTC
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.
Comment 20 Katrin Fischer 2020-04-18 23:18:38 UTC
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.