Add information on workload to home page
It may be useful to have an indication of number of studies carried out using each imaging system in the past week and month on the home page. This may form the first part of a dashboard that managers may find useful.
Comments (62)
-
reporter -
reporter It would be easy to allow configuration of the time periods used for the two workload figures, and even enable these to be different for each type modality. Could have charts of studies per time period (day/week/month/year) plotted over time, with a series per room.
-
reporter Added configurable time periods to user profile to use for summary workload figures on home page. Added code to use these values to show appropriate totals on the home page. Using defaults of 7 and 28 days; also using these values if no user is logged in. Need to enable the user to change these values via options. References issue
#658→ <<cset a911d90a94a3>>
-
reporter Created form for user to change the time periods used to sum studies on home page. References issue
#658→ <<cset a81c7db60f95>>
-
reporter The updated urls.py required by the new form. References issue
#658→ <<cset 4033980b1c5b>>
-
reporter Documented new home page config option. Updated revised UserOptionsMenu.png width in other docs where it is explicitly set. Doc changes only [skip ci]. References issue
#658→ <<cset 0f0d686ba961>>
-
reporter Fixed issue that I caused by adding extra data to what was being passed to the home templates. This was causing extra blank rows to appear in the modality tables. I've fixed this by passing the home page config as a separate variable. References issue
#658→ <<cset 2dd4117a8051>>
-
reporter Removed typo. References issue
#658→ <<cset a5d9e6ab0ee1>>
-
reporter Note to self: the code in the branch for this issue includes the code to sort the tables on the home page.
-
reporter Created a variable to contain the modality studies which is then reused. Neater code; not sure whether it results in fewer database hits. References issue
#658→ <<cset 5acff1bc5f65>>
-
Do you not have Django debug toolbar set up?
-
reporter I don't know. My settings.py includes a line relating to the debug toolbar in MIDDLEWARE_CLASSES, and urls.py includes an if settings.DEBUG that mentions debug_toolbar.urls, but I don't know how to see or use the toolbar.
-
reporter OK. I have it working now, but I don't think that it's showing me the time taken or number of queries for the AJAX calls that retrieve the details about studies for each modality. Have you managed to get it to do that?
-
reporter Ok. I have it working for AJAX requests now (installed this panel: https://github.com/djsutho/django-debug-toolbar-request-history). There's no difference in the number of database hits or time required between the two versions of my code.
-
reporter Fixing conflicts caused by home page sorting code being present in develop and this branch. References issue
#658→ <<cset 53d3c7c4dbc1>>
-
reporter Pycharm formatting changes. References issue
#658→ <<cset 07446a91dbec>>
-
reporter Adding some doc strings to appease Codacy. Doc changes only [skip ci]. References issue
#658→ <<cset e77a4b809347>>
-
reporter @edmcdonagh, I've just created a stage branch of this so that you can see it at http://testing.openrem.org/openrem/. If you log in as demo you'll see that I've changed the time periods to 365 and 3650 days so that you can see what this looks like on the home page. Any thoughts?
-
I like it, particularly if it loads in the same time as without. For smaller screens, maybe "Number in last x days"? Otherwise it folds to four lines at 800 wide, or three lines at 1024 wide.
-
reporter Shortening length of workload titles on home page. HTML text change only [skip ci] References issue
#658→ <<cset 0e651ce321d1>>
-
reporter There is a performance hit to having the workload data on the home page. For example, my live system has 249,000 radiographic studies across 20 rooms. CPU time for the DX AJAX call is 2.5 s without the workload info, and 4.0 s with the workload info. However, it doesn't feel slower due to the main page appearing immediately, quickly followed by the modalities with fewer rooms (CT, fluoroscopy), then mammo, then radiographic.
-
Hmm. That's quite a difference. On my old server, that would have been a killer! I'll try it out with my database when I get a chance.
It could be that we should populate the two new columns as additional AJAX calls - we need to make sure the user can get through to clicking on the system off their choice as quickly as possible.
-
reporter I'll add code to populate the new columns as an additional AJAX call.
-
reporter @edmcdonagh, this is causing me some problems. I can't work out how to update each row of the summary tables with the workload data as a result of a new AJAX call. In the first AJAX call I was going to label the two workload cells of each row of the table with a unique id, based on a concatenation of display name, modality and delta a or b. I was then going to use these id values in the second AJAX call to update the values. However, I can't guarantee that the display name will only contain valid characters that can be used as an HTML id label. Any thoughts?
-
I'd need to remind myself how it works. Is the code that does a similar thing on the system name config page at all instructive?
-
reporter It should work if I use the database key of each display name.
-
reporter Modified code so that workload figures for home page are obtained in a separate AJAX call. I'm not sure it works entirely as I'd like, but it is a start. References issue
#658.→ <<cset 51648f7dcbb1>>
-
reporter This current commit is now on http://testing.openrem.org
-
I've pulled this onto my laptop, and something is not working correctly because different modalities that have similar numbers and date ranges are showing with some at 0 and some with hundreds in the date ranges I've selected.
I'll need to concentrate a but harder to work it through though!
-
reporter Fixed error in code that caused incorrect workload data. Now obtaining studies using display_name__exact in the workload view, rather than using pk. References issue
#658→ <<cset 77359eb7ce6e>>
-
Ah, so each entry in the display name table is a pk, several of which will have the same display name.
-
reporter Although the code works it isn't very efficient, as it goes through every entry in the display name table, rather than just the unique names. Not sure how to obtain a list of unique display names, together with the pk of the first entry of this name in the table.
-
reporter Improved code so that only unique display names are used in the home page views, rather than every entry in the display name table. References issue
#658→ <<cset 58be16ee8716>>
-
reporter Created home page admin options so that an OpenREM administrator can choose whether to have workload stats calculated and displayed on the home page or not. References issue
#658→ <<cset 5cebbdd922ef>>
-
reporter I've just added a HomePageAdminSettings table to models.py. I purposefully kept the name general as we may want to add other fields to this as time goes on.
-
reporter @edmcdonagh this is now sorted as far as I am concerned (except for updating the documentation and changes files). The current code is on testing.openrem.org. There's a new home page admin-level setting that can switch the display and calculation of the workload data on or off.
-
Would it make more sense to redirect to the homepage on save, rather than remain on the options page?
-
I want to make a 0.8.2 bug fix release after I attempted to use OpenREM to query-retrieve directly our old GE LS 16 RT, and found it didn't send back mandatory tags (surprise!) such as SOPClassUID and sometimes series level modality, plus (more importantly) the code fell over if the optional ModalitiesInStudy was not returned as a tag. Ultimately, I now have it querying the scanner using the Toshiba flag to get my data - so thanks!
Which is a long winded way of saying why don't you tag this with 0.8.2 and put in a pull request when the docs are done?
-
reporter Maybe, but my brain is preventing me from working out how to do that...
-
reporter - changed milestone to 0.8.2
-
Something about putting a return redirect(hompage) near https://bitbucket.org/openrem/openrem/branch/issue658displayWorkloadOnHomePage#Lopenrem/remapp/views.pyT2886 I think
-
reporter Added redirect to home after user changes workload preferences. References issue
#658→ <<cset a8e89059e208>>
-
reporter Removed unrequred commented-out import statement [skip ci]. References issue
#658→ <<cset a2e45f3d627d>>
-
We've made the same choice throughout the code, but I think rather than redirecting to
'/openrem/'
we should really useHttpResponseRedirect(reverse(home))
, I think.I am worried about the changes in Pull Request #223 and issue
#667and whether it will work throughout or if all our hard-coded URLs will mess it up!Obviously I'm not suggesting changing them all in this branch, but if we could use the more Django way for new code then we might be in a better place Django docs for ref: https://docs.djangoproject.com/en/1.8/ref/urlresolvers/#django.core.urlresolvers.reverse
-
reporter Changing redirect to use a more Django-esque method. References issue
#658→ <<cset ee3628b511b8>>
-
reporter I don't think it would be much work to replace all the hard-coded urls with a more Django-esque method.
-
You are probably right. Can you throw it into an issue so we remember?
-
reporter Altered menu entry for consistency. References issue
#658→ <<cset 9ab2c562bf0c>>
-
reporter Updating docs for home page settings [skip ci]. References issue
#658→ <<cset e76cf9549da4>>
-
reporter Updating docs for home page settings [skip ci]. References issue
#658→ <<cset ad1ed07dafd9>>
-
reporter Updating docs for home page settings [skip ci]. References issue
#658→ <<cset b8b5fb1bc9fe>>
-
reporter Updating docs and doc link for home page settings [skip ci]. References issue
#658→ <<cset 890834661a1b>>
-
reporter - changed status to resolved
Updated changes files. Fixes issue
#658→ <<cset c4ae9eb677b4>>
-
reporter Updated release doc for 0.8.2 with line describing the workload stats that can now be displayed on the home page. References issue
#658→ <<cset a65a724b868e>>
-
- changed status to open
Sorry, @dplatten - I'd like to keep it open until it is merged into develop, else I lose it in the issues list (I know the PR is open, so I'd see it there).
I'd like to pull it into my test system to look it over once more if that's ok before merging - or maybe if you could throw the latest onto testing I could look there?
Thanks Ed
-
reporter @edmcdonagh that's no problem. The latest code is on the way to the testing site. I'd suggest you look at it on your own test system too, as the testing system is really fast and not representative of a real situation.
-
- changed status to resolved
Merged in issue658displayWorkloadOnHomePage (pull request #225)
Fixes Issue
#658Approved-by: Ed McDonagh ed@mcdonagh.org.uk
→ <<cset 828182a7316f>>
-
@dplatten - user level home page options could do with a note about it needing the workload bit to be enabled by an administrator.
Also, the Please wait, querying database row is one column too short.
-
reporter Added info message to inform user if homepage workload stats are switched off when they are viewing the homepage options. The message is different for a normal user and admin user. I've also amended the colspan of the homepage modality tables so that it is correct. References issue
#658→ <<cset fdecf9a4b1ec>>
-
reporter Added user home page options entry back onto the config menu. This only appears if the display of workload stats is activated in the admin options, and then only when the user is on the home page or the user- or admin-level home page option views. References issue
#690and issue#658→ <<cset 87f0848f39b9>>
-
reporter Updated changes files. References issue
#690and issue#658→ <<cset c9cb93c643b6>>
-
- changed milestone to 0.9.0
- Log in to comment
I should have said that I've already implemented this on my system (see the attached screenshot).