https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9567
--- Comment #8 from Christopher Brannon <cbran...@cdalibrary.org> --- If a table was kept for something like this, it could go much further than just favorite reports. For example, lets call this the 'follow_me' table. Maybe the 'follow_me' table has the following columns: borrowerid | tableid | function | object - The borrowerid would be straight forward: who this is for. - The tableid would reference the table this has the effect on. So, for example, the 'table_reports' - The function in this case would be 'favorites' - The object would be the 'report_id'. The same 'follow_me' table could also be used down the road to record other settings you want to remain consistent wherever you go. So maybe you want some columns on the check-out table to be different than the default. - The borrowerid again indicates who this is for. - The tableid would reference the 'issues-table'. - The function would be maybe 'hide' if you want a particular column always hidden, or 'show' if you always want it to show. - The object would be a reference to the particular column, such as price. I'm not sure how the current columns are identified with the current settings, but you would probably use whatever is used in the settings already for consistency. Maybe a cataloger only wants to see certain shelving locations, instead of seeing everything available. Or maybe the desk and register could be saved in this table as well. I hope that makes sense. I'm just trying to think of a way something of this nature could be more useful and practical down the road for more than one thing. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/