The Admin main page has a lot of empty space that could be utilised for library wide information. Other ILS show local and global information on various pages e.g. - Number of currently checked out items - Number of items in my branch - Number of overdues - Total Bibs catalogued in last 7 days. How about the addition of a Koha dashboard page to use this space and present local and global library information within the users context?
Created attachment 5249 [details] Mock up of Admin Dashboard Mock up screen of Admin Dashboard.
In your idea/plans, can the list of what is in the dashboard be edited by the library ? will it be hardcoded ? modular system ? Libraries will be highly interested by this feature, for sure. But i'm also sure that each of them will ask for different views A suggestion: we (well, you, if you code it ;-) ) : dashboard could retrieve datas to display from saved reports. Something like : table dashboard = dashboardid report_id position (the position in dashboard) Then you run the results, and display them in the dashboard. Managing the dashboard will mean for the libraries defining reports to run, and attaching them to the dashboard. We could provide some standard/basic/usual reports during installation. Other suggestion : this kind of dashboard, appearing on homepage, can be highly CPU consuming for large databases. I strongly suggest to cache the result in a file and update the dashboard only once every night. Or remove it from the homepage to have a dashboard specific one, but that's not your goal, and I agree the dashboard on homepage is an amazing idea) HTH
(In reply to comment #2) > In your idea/plans, can the list of what is in the dashboard be edited by the > library ? will it be hardcoded ? modular system ? Libraries will be highly > interested by this feature, for sure. But i'm also sure that each of them will > ask for different views In this release the data will be hard coded. If accepted I will certainly add the ability to show/hide details under the SysPref submenus of DashBoardDisplayed. > > A suggestion: we (well, you, if you code it ;-) ) : dashboard could retrieve > datas to display from saved reports. Something like : > table dashboard = > dashboardid > report_id > position (the position in dashboard) > > Then you run the results, and display them in the dashboard. > Managing the dashboard will mean for the libraries defining reports to run, and > attaching them to the dashboard. We could provide some standard/basic/usual > reports during installation. Sounds great. However, if everyone agreed, I would like to get a limited release up and integrated first, if possible and then add features as patches etc. > > Other suggestion : this kind of dashboard, appearing on homepage, can be highly > CPU consuming for large databases. I strongly suggest to cache the result in a > file and update the dashboard only once every night. Yes, we have been toying with this idea too. At the moment, the number of selects is increasing and although they are only counts* it isn't ideal to have those queries running directly with every main page load. The only downside we had to this is that it introduces another cron job and makes the data somewhat stale (until updated at night). Is this the general consensus? Generate a static page nightly? > Or remove it from the > homepage to have a dashboard specific one, but that's not your goal, and I > agree the dashboard on homepage is an amazing idea) > > HTH
> > Other suggestion : this kind of dashboard, appearing on homepage, can be highly > > CPU consuming for large databases. I strongly suggest to cache the result in a > > file and update the dashboard only once every night. > > Yes, we have been toying with this idea too. At the moment, the number of > selects is increasing and although they are only counts* it isn't ideal to have > those queries running directly with every main page load. The only downside we > had to this is that it introduces another cron job and makes the data somewhat > stale (until updated at night). Is this the general consensus? Generate a > static page nightly? Well, the static is definetly better if you want it on homepage ! But, depending on how deep you want to go, you can also : * have a button "update" available only for patrons with a (newly created) permission. That would result in semi-static stats : the boss can update, it's not updated everytime the page is loaded * you could use memcache for results also : if memcache is set, the retrieve the result from memcache. If it's not set, calculate everytime In fact, there are many possibilities ;-)
Chris and I were discussing the possibility of adding a charting reporting interface to koha. This would also be able to make something like this look nice. For example, a graph that showed issues per hour for the past 12 hours, or something like that. Just giving you more stuff to think about ;)
And my 2cents, if you could make it hand back json, then we could do graphs like http://stats.workbuffer.org/graph.html Really easily, all client side. All these comments mean one thing though, its a good idea, and I agree your approach to get something out there and refine is a good approach.
BibLibre is investigating using a tool like Jasper Reports for graphical displays. I think that a dedicated tool will be easier/give a better result than developing something new. Stay concentrated on the core of Koha.
Hi Barry, first of all - I think the dashboard is a great idea! I also think the numbers in the mock up are a great start and I will be happy to test once your patches arrive on the list. I have only a small design suggestion to make: Perhaps it could be placed in a column on the right or left, so it stays on top and is always visible when you go to the start page. I think a reporting tool will probably provide more flexibility to people who know how to use it and how to make it work with Koha - it will always require a certain amount of database knowledge and such. That said I think some build in graps and pies in Koha would be a very nice addition and will make a lot of libraries really happy.
Created attachment 6317 [details] [review] Patch implement enhancement First run of enhancement patch.
Created attachment 6389 [details] [review] New Amended patch This patch should be the final patch needed to implement this feature. I had omitted a file in the last upload and have added that now.
Hi Barry, I am sorry, your patch does not apply on master. Could you please fix and resubmit? Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y Applying: Bug 6828[ENH] - Add basic Dashboard for staff users. /home/katrin/kohaclone/.git/rebase-apply/patch:61: trailing whitespace. BEGIN { /home/katrin/kohaclone/.git/rebase-apply/patch:62: trailing whitespace. $VERSION = 3.01; /home/katrin/kohaclone/.git/rebase-apply/patch:64: trailing whitespace. @EXPORT = qw(&number_of_items_library_xml &number_of_borrowers_library_xml &number_of_issues_library_xml &number_of_biblios_xml &number_of_loan_history_system_xml /home/katrin/kohaclone/.git/rebase-apply/patch:85: trailing whitespace. /home/katrin/kohaclone/.git/rebase-apply/patch:93: trailing whitespace. warning: squelched 50 whitespace errors warning: 55 lines add whitespace errors. Using index info to reconstruct a base tree... <stdin>:61: trailing whitespace. BEGIN { <stdin>:62: trailing whitespace. $VERSION = 3.01; <stdin>:64: trailing whitespace. @EXPORT = qw(&number_of_items_library_xml &number_of_borrowers_library_xml &number_of_issues_library_xml &number_of_biblios_xml &number_of_loan_history_system_xml <stdin>:85: trailing whitespace. <stdin>:93: trailing whitespace. warning: squelched 51 whitespace errors warning: 55 lines applied after fixing whitespace errors. Falling back to patching base and 3-way merge... Auto-merging installer/data/mysql/sysprefs.sql Auto-merging installer/data/mysql/updatedatabase.pl CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt Auto-merging mainpage.pl CONFLICT (content): Merge conflict in mainpage.pl Failed to merge in the changes. Patch failed at 0001 Bug 6828[ENH] - Add basic Dashboard for staff users. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort".
Created attachment 10058 [details] [review] Bug 6828 - Add basic Dashboard for staff users. This enhancement adds the option of switching on/off a Dashboard on the Staff users mainpage. The information displayed is specific to the users logged in branch but will also show a system wide overview. Its visibility is controlled by a new SysPref. This first revision takes its data from an XML file which needs to be populated on a cronjob. The file to run is in misc/migration_tools/dashboard_xml.pl. The usual Koha env will need to be set for the user running the script.
Created attachment 10059 [details] [review] Bug 6828 follow-up: adapt dashboard to new staff client theme This follow-up makes a few cosmetic changes: * Moves the dashboard to underneath the "pending" panel * Switches the layout to CSS-based instead of table-based * Makes the error message translatable * Reindents some sections of the added code to make things more readable
Installed patch yesterday, looked great, but in the meantime I get "Does not apply" error, sorry. Applying: Bug 6828 follow-up: adapt dashboard to new staff client theme error: patch failed: koha-tmpl/intranet-tmpl/prog/en/css/staff-global.css:2274 error: koha-tmpl/intranet-tmpl/prog/en/css/staff-global.css: patch does not apply Additionally, it would be nice to have a span around the line "last updated..." to make it possible to format or to hide it with CSS. Marc
Created attachment 10217 [details] [review] [SIGNED-OFF] Bug 6828[ENH] - Add basic Dashboard for staff users. This enhancement adds the option of switching on/off a Dashboard on the Staff users mainpage. The information displayed is specific to the users logged in branch but will also show a system wide overview. Its visibility is controlled by a new SysPref. This first revision takes its data from an XML file which needs to be populated on a cronjob. The file to run is in misc/migration_tools/dashboard_xml.pl. The usual Koha env will need to be set for the user running the script. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 10218 [details] [review] [SIGNED-OFF] Bug 6828 follow-up: adapt dashboard to new staff client theme This follow-up makes a few cosmetic changes: * Moves the dashboard to underneath the "pending" panel * Switches the layout to CSS-based instead of table-based * Makes the error message translatable * Reindents some sections of the added code to make things more readable Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
QA Comments: 1/ I think the Copyright is not the good one :) (+# Copyright 2000-2002 Katipo Communications) 2/ SQL reserved words must be uppercased 3/ all files are not pertidied (indentation, etc.) 4/ intranet-main.tt > Tables does not contain a body tag. However, its contain style (width="400") whitch can be set into the css file. 5/ The first table (Overview) contains an empty row (the last one). 6/ The value of the syspref DashBoardDisplayed is send to the template from C4/Auth.pm. I think it can be sent from the mainpage.pl 7/ Why the default value for DashBoardDisplayed is "show" ? We have to launch the dashboard_xml.pl script then I think the default value could be "Don't show" Marking as Failed QA
This still seems like a really neat idea. It's been 5 years + since the idea first came up. Is this still in the works?
Created attachment 60692 [details] [review] Bug 6828[ENH] - Add basic Dashboard for staff users. This enhancement adds the option of switching on/off a Dashboard on the Staff users mainpage. The information displayed is specific to the users logged in branch but will also show a system wide overview. Its visibility is controlled by a new SysPref. This first revision takes its data from an XML file which needs to be populated on a cronjob. The file to run is in misc/migration_tools/dashboard_xml.pl. The usual Koha env will need to be set for the user running the script. Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 60693 [details] [review] Bug 6828 follow-up: adapt dashboard to new staff client theme This follow-up makes a few cosmetic changes: * Moves the dashboard to underneath the "pending" panel * Switches the layout to CSS-based instead of table-based * Makes the error message translatable * Reindents some sections of the added code to make things more readable Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Just a rebased patch. It seems that the way this feature has been implemented need to be rethink.
(In reply to Cab Vinton from comment #18) > This still seems like a really neat idea. > > It's been 5 years + since the idea first came up. > > Is this still in the works? Did you test the rebase patches?
(In reply to Jonathan Druart from comment #22) > (In reply to Cab Vinton from comment #18) > Did you test the rebase patches? If this is really directed at me, No. Just a humble librarian who has no idea how to test patches, etc. Willing to consider a career change, however ;-) Cab
There are sandboxes to test patches without any technical skills. Wrong answer ;)
(In reply to Jonathan Druart from comment #24) > There are sandboxes to test patches without any technical skills. Wrong > answer ;) Ah, not familiar w/ those. Think this would be a great training session for the Koha libraries in New England. Will contact our friends at ByWater & see if they have or know of anyone in our neck of the woods.
Hi Cab, just some additional info: https://wiki.koha-community.org/wiki/Sandboxes There is also a video on how to use them. Please feel free to jump into chat if you get stuck too!
(In reply to Katrin Fischer from comment #26) > Hi Cab, just some additional info: > https://wiki.koha-community.org/wiki/Sandboxes > There is also a video on how to use them. Please feel free to jump into chat > if you get stuck too! Thank you, Katrin. I'd found that info previously, but missed the tutorial video. Great job by Nicole as usual. Feel comfortable now w/ trying my first sign off :-)
(In reply to Jonathan Druart from comment #22) > Did you test the rebase patches? So I've learned how to sign off on patches, but the status of this patch is Failed QA. If a dashboard XML file needs to be created, then not sure whether testing via a sandbox would work. Tried Sandbox 06 anyway & got the following: The sandbox you've requested is not ready. Some problems occurred applying patches from bug 6828: <h1>Something went wrong !</h1>Applying: Bug 6828[ENH] - Add basic Dashboard for staff users. .git/rebase-apply/patch:483: trailing whitespace. warning: 1 line adds whitespace errors. Using index info to reconstruct a base tree... M C4/Auth.pm M installer/data/mysql/sysprefs.sql M installer/data/mysql/updatedatabase.pl M koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/admin.pref M koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt M mainpage.pl .git/rebase-apply/patch:483: trailing whitespace. warning: 1 line applied after fixing whitespace errors. Falling back to patching base and 3-way merge... Auto-merging mainpage.pl Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/intranet-main.tt Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/admin.pref CONFLICT (content): Merge conflict in koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences/admin.pref Auto-merging installer/data/mysql/updatedatabase.pl CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl Auto-merging installer/data/mysql/sysprefs.sql CONFLICT (content): Merge conflict in installer/data/mysql/sysprefs.sql Auto-merging C4/Auth.pm CONFLICT (content): Merge conflict in C4/Auth.pm error: Failed to merge in the changes. Patch failed at 0001 Bug 6828[ENH] - Add basic Dashboard for staff users. 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. Bug 6828 - Add Admin Dashboard for staff users. 10217 - [SIGNED-OFF] Bug 6828[ENH] - Add basic Dashboard for staff users. 10218 - [SIGNED-OFF] Bug 6828 follow-up: adapt dashboard to new staff client theme 60692 - Bug 6828[ENH] - Add basic Dashboard for staff users. 60693 - Bug 6828 follow-up: adapt dashboard to new staff client theme Apply? [(y)es, (n)o, (i)nteractive] Patch left in /tmp/SIGNED-OFF-Bug-6828ENH---Add-basic-Dashboard-for-s-EpoHfa.patch .
First problem here was that there was a set of old patches not obsoleted. So the conflict was inevitable. I've fixed this, but the other patches still don't apply. @Cab - you are correct, because of the cronjob and XML file needed this is not testable by a sandbox. Generally if you are looking for some easier ones, we have a keyword "Academy" on bugzilla, that we use to mark them. If there are none, feel free to bug me and I am happy to take a look at the queue with you.