Home› Analyst Portal

Activity History?

Jason_MeyerJason_Meyer Customer Advanced IT Monkey ✭✭✭
in Analyst Portal
Where is the HISTORY of an ACTIVITY stored?   I'm looking for the history of ACTIVITIES that get returned to or skipped or completed.  Was thinking/hoping that these tasks would show up in the HISTORY of the associated work item.

Best Answer

Answers

  • Marek_LefekMarek_Lefek Customer Advanced IT Monkey ✭✭✭
    Is there a possibility to get history value of WorkItem  by SQL eg. who set status to Cancel or Completed?
  • Ryan_LaneRyan_Lane Cireson Support Advanced IT Monkey ✭✭✭
    I've been working on additional history functionality if anyone is interested.  It uses the same Kendo templating system that the original work item's History tab uses but allows you to select related activities as well.

  • Marek_LefekMarek_Lefek Customer Advanced IT Monkey ✭✭✭
    That's looks great. And Has all activities :) 

  • Ryan_LaneRyan_Lane Cireson Support Advanced IT Monkey ✭✭✭
    edited October 2018
    If you're interested in trying it out, I've thrown the controller.js and view.html up at https://github.com/ryanlanegit/CiresonPortal/tree/master/CustomSpace/Scripts/forms/predefined/history.
    There are several ways to go about adding the new items to the portal:
    1. Replace the original files in /Scripts/forms/predefined/history
    • Unrecommended -- Will be reverted on updating the portal
    -OR-
    2. Add the files to your CustomSpace directory and create a redirect in IIS.
    • PRO: Less work to implement
    • PRO: Leaves Cireson files Intact
    • CON: Maintenance/Recreation of the redirect in IIS on updating the portal
    -OR-
    3. Replace the RequireJS reference in formBuilder.js, compile the RequireJS and then create an IIS redirect to the built file.
    • PRO: Better Performance for clients and decreased load times
    • CON: Much more work to implement 
    • CON: Maintenance/Recreation of the redirect in IIS on updating the portal
    • CON: Any changes to included files will require a recompile of RequireJS.

    You may need to update the initial require string pointing to view.html in the controller.js file to point to the final location.
    The dropdown isn't perfect as you can't expand and collapse parents but should follow the overall format of all activities related to the work item.

    It's still a work in progress as I have not done much beyond the initial layout earlier this year so any suggestions or improvements would be much appreciated!
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    #2 seems like the best balance to me, personally.

    I run the installer as part of a larger PS script that fixes a lot of the IIS issues that are caused by the portal installer bulldozing my site settings (it adds them back, afterward).  Therefore, I can just add it to my installation script that I am already running.

    Also, there is already a performance hit to the History tab.  Everything about it is slow.  If this redirection is part of an async load, then it should be no more noticeable on a tab that users already are accustomed to waiting several seconds on.
  • Ryan_LaneRyan_Lane Cireson Support Advanced IT Monkey ✭✭✭
    edited October 2018
    EDIT: Just realized I meant page load times and not history load times but was vague on the details.  Loading object history from the ECL table is a very slow process especially with larger table sizes which can really only be sped up with some additional indexes and running maintenance workflows to clear old data.

    @Tom_Hendricks I initially went with #2 but ended up on #3.  The large decrease in load times for almost every view thanks to no longer needing to load an additional 100+ dependencies definitely made up for the work setting it up and minor maintenance on site updates.
    Here's a fresh load of an Incident:

    And My Work:


  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    @Ryan_Lane I looked around on your GitHub page and gained a passing understanding after seeing the examples, but I would not mind learning a bit more about the technique you use.  Those times are certainly better than 10-20 seconds...

    Just on the surface, I like #2 better however, performance increases might push me over to #3 if I can put together a straightforward process for building/rebuilding that file.
  • Ryan_LaneRyan_Lane Cireson Support Advanced IT Monkey ✭✭✭
    Tom_Hendricks said:
    ...10-20 seconds...
    Ouch, that's rough.  Load times and the portal don't always agree more often than not in my experience.  What are your typically load times before and after a cache refresh for home, team work, and something simple like a new Incident?
    Here's what I'm getting with rjs compilation and a couple of minor IIS changes:
    Page Cache Cleared Requests Transferred Finish DOMContentLoaded Loaded
    Home TRUE 102 3.9MB 5.27 3.43 5.36
    Home FALSE 100 269KB 3.22 1.77 2.73
    Team Work TRUE 55 3.8MB 4.73 2.98 4.38
    Team Work FALSE 53 139KB 3.21 1.83 3.05
    Incident/New TRUE 74 3.8MB 7.09 3.35 7.04
    Incident/New FALSE 72 180KB 5.57 2.38 5.5
Sign In or Register to comment.