1. OpenREM Avatar OpenREM
  2. OpenREM
  3. OpenREM
  4. Issues

Add information on workload to home page

Issue #658 resolved
David Platten created an issue

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)

  1. David Platten reporter

    I should have said that I've already implemented this on my system (see the attached screenshot).

  2. David Platten 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.

  3. David Platten 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>>

  6. David Platten 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>>

  7. David Platten 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>>

  9. David Platten reporter

    Note to self: the code in the branch for this issue includes the code to sort the tables on the home page.

  10. David Platten 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>>

  12. David Platten 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.

  13. David Platten 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?

  18. David Platten 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?

  19. Ed McDonagh

    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.

  21. David Platten 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.

  22. Ed McDonagh

    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.

  24. David Platten 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?

  25. Ed McDonagh

    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?

  27. David Platten 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>>

  29. Ed McDonagh

    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!

  30. David Platten 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>>

  31. Ed McDonagh

    Ah, so each entry in the display name table is a pk, several of which will have the same display name.

  32. David Platten 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.

  33. David Platten 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>>

  34. David Platten 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>>

  35. David Platten 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.

  36. David Platten 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.

  37. Ed McDonagh

    Would it make more sense to redirect to the homepage on save, rather than remain on the options page?

  38. Ed McDonagh

    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?

  44. Ed McDonagh

    We've made the same choice throughout the code, but I think rather than redirecting to '/openrem/' we should really use HttpResponseRedirect(reverse(home)), I think.

    I am worried about the changes in Pull Request #223 and issue #667 and 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

  46. David Platten reporter

    I don't think it would be much work to replace all the hard-coded urls with a more Django-esque method.

  55. Ed McDonagh
    • 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

  56. David Platten 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.

  58. Ed McDonagh

    @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.

  59. David Platten 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>>

  60. David Platten 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 #690 and issue #658

    → <<cset 87f0848f39b9>>

  63. Log in to comment
Assignee
Type
proposal
Priority
minor
Status
resolved
Component
Interface
Milestone
0.9.0
Votes
0
Watchers
1
Jira Software: the preferred issue tracker for Bitbucket. Join the team!