Bug 9567 - Favorite reports per user
Summary: Favorite reports per user
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Reports (show other bugs)
Version: Main
Hardware: All All
: P5 - low new feature with 1 vote (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
: 34925 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-02-07 17:18 UTC by Nicole C. Engard
Modified: 2024-02-28 17:25 UTC (History)
12 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2013-02-07 17:18:38 UTC
It has been suggested that in order to navigate to your favorite reports, or the reports you use most often, Koha should have a way to mark, or create a list, of your favorite reports. When you log into Koha, and go to the reports page, there will be quick links to your most used reports.
Comment 1 Lisette Scheer 2018-09-12 16:32:36 UTC
This would be very helpful. 
We have 49 libraries and most of those libraries have specific reports that they use that are not necessarily used by all the libraries. 
It would help because we have about 600. 

I know there is an AV that lets you create tabs, but you can only add reports to 1 tab each, so that isn't helpful in this case. 

Lisette
Comment 2 Cab Vinton 2018-10-20 21:04:24 UTC
Here's a temporary workaround -- Use MySQL's comment syntax & a unique string within the body of the report to identify favorite reports (initials, passphrase, etc.)

For example:

/* JTG */

/* JTG FMV */

/* rugbytuna */
Comment 3 paxed 2018-10-23 05:11:02 UTC
I see couple "easy" ways of doing this, without needing database changes: 1) All in the client side, with cookies and javascript, or 2) Using a borrower attribute to store the favorite report IDs
Comment 4 Katrin Fischer 2019-04-27 22:52:28 UTC
Still a nice idea :)
Comment 5 Katrin Fischer 2023-10-06 22:21:07 UTC
*** Bug 34925 has been marked as a duplicate of this bug. ***
Comment 6 Christopher Brannon 2023-10-06 22:31:43 UTC
(In reply to paxed from comment #3)
> I see couple "easy" ways of doing this, without needing database changes: 1)
> All in the client side, with cookies and javascript, or 2) Using a borrower
> attribute to store the favorite report IDs

I would not be in favor of anything that wouldn't follow you.  Staff bounce around on different computers.  This would be a difficult way to manage favorites.  A table for tracking pages/tables/and borrower ids would be ideal.
Comment 7 Christopher Brannon 2024-01-02 23:51:01 UTC
(In reply to Cab Vinton from comment #2)
> Here's a temporary workaround -- Use MySQL's comment syntax & a unique
> string within the body of the report to identify favorite reports (initials,
> passphrase, etc.)
> 
> For example:
> 
> /* JTG */
> 
> /* JTG FMV */
> 
> /* rugbytuna */

One major reason this doesn't work well is that it requires either everyone to have editing capabilities to mark a report as their favorite, or some poor editor person has to be the schmuck to do it for them. This work around works for me, but not for everyone else.
Comment 8 Christopher Brannon 2024-01-03 00:20:34 UTC
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.