Cireson Partners, Customers and Community members share your customizations and examples here to help benefit the community as a whole to earn Kudos and badges.

DISCLAIMER

All files and projects located here are provided and come "as-is" and without any warranty or support. Use at your own risk. Your use of Community Uploads is subject to our Terms of Use.

Cireson does not and will not support or maintain these enhancements, extensions, and scripts.

For Team Cireson uploads click here.

Dashboard tables - Open items other than work items

Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
edited January 2018 in Community Uploads
If you use the SQL Table widgets in the Cireson portal dashboard, then chances are good that you have created a table with rows that are not work items.  Perhaps you wanted to create a custom view of KB articles or Software Assets, for example.  Maybe even a personalized list of purchase orders for equipment that will be delivered to your office location?

Problem:  ALL SQL table widgets think that everything is a work item.  When you click a row, and it doesn't see a work item ID associated, it opens the Work Item Search page in the same window you were just using.  This can be frustrating for users who were expecting to see a KB article in another tab, for example.

Solution: This code, if it sees a table column with one of several names, will disable the default click behavior and replace it, so that the item in the row will open in a new window/tab based on its type.  For example, if a KB article ID is in one of the columns, the article will open in a new tab.  If the asset ID for a hardware asset is in one of the columns, the hardware asset will open in a new tab.

Caveats, Known Issues:
  • Consider this a beta or a v1.  I am quite sure that it could be optimized further, and I invite feedback or contributions.  (I can create a GitHub repo if there is interest)
  • The override occurs after all grids on the page are finished loading.  Although I could not force this to load slowly enough in my lab to observe the problem, it is theoretically possible that a user could click on a row in a grid before this change has been applied to it, sending them to the Work Item Search page.  Again, I was unable to observe this, though.
  • This is essentially a hack.  It would be much cleaner to define the "change" event of the grid when it is bound, but it is not possible to affect the initial binding, and attempts to follow the suggested methods of .bind("change" func().... and modifying the databound event / re-fetching do not have any effect on the grids.  I look forward to the day when Cireson builds this functionality in and I can remove this code from my site!
  • With my apologies, I did not know who to attribute the loadscript function to!
  • EDIT: the ID column names need to match a list at the top of the DB_customTableItemUrl.js file.  Unfortunately, it is case-sensitive at this time.  (Match the case in your SQL script--it does not matter if the page changes it to uppercase in the column header).  You may add additional entries or change these to suit your own needs.

A few other notes:

My implementation of the portal has several handlers for different page types in the custom.js file, and I was also already using the outer mutation observer to load a different fix for all dashboards, in addition to this one.  That is why this is contained in 3 files and why some of it is written the way it is.  Even with all of this in mind, I still invite feedback or contributions to help optimize it, if you find this to be useful.

EDIT 2: IE absolutely hated this script.  Attachment has been replaced with a version confirmed to play nice with Chrome, Firefox, and IE.

EDIT 3: Perhaps you didn't like how clicking a column to filter/sort/move it would try to open another page, instead of doing what you wanted it to?  I wasn't a fan, either.  Now it doesn't do that anymore.  The custom.js now sets this to run on document.ready(), explicitly.

Comments

  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    This new version runs much more efficiently in general, handles single or multiple  grids on simpler dashboard pages quite well, and is no longer causing performance issues on the more complex dashboard pages.

    Known issue: On complex (many widgets) dashboard pages, it is possible that this enhancement will not be applied as soon as one would like, causing the click to open the work item search.  This is an improvement opportunity, and I would definitely welcome other thoughts/feedback for solving it.
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    Bug fixes:
    • links (click event) were lost when the grid refreshed, such as when the number of results or the page was changed.  Now, it is preserved.
    • Performance appears to be better (feedback welcome).

    Change:

    The leftmost column(s) will highlight in blue, similar to the My Work table, and can be clicked to open the item.  The rest of the row is now clickable without opening the highlighted item.  The columns that are highlighted are configurable by editing the column names in the new linkColName array near the top of the script.

  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    Bug fixes:
    • Grouped rows would try to open a link when clicked instead of expanding/collapsing as expected.  Grouped rows now function correctly.
  • James_JohnsonJames_Johnson Customer IT Monkey ✭
    Thank you so much for the scripts Tom!  This was very helpful in its purpose and for helping me to learn more about custom scripting with the portal.

    I did have to make a few changes to the script though to get it to work.  I had to update the keys in typeIdTbl to be all uppercase because all of my sql table headers come in full caps, not sure if that's just a me problem, and I had to call isWorkItemTable on the kGrid, not the kTable.

    Thanks again for the great work!
    James
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I am glad it is helpful!  I think I owe a fairly significant update though.  Portal v9 broke multiple parts of this, in addition to needing the change you just mentioned.  I've got it working properly again in my environment, but it needs to be refactored a little before it can be shared.

    FYI, the SQL headers in caps was an issue in one of the later versions of v8 (after 8.9.4 I think) that is gone again in v9.  
  • James_JohnsonJames_Johnson Customer IT Monkey ✭
    edited April 17
    That makes sense then, I'm on version 8.9.5. 

    Edit:  If I get it up and running I'll post the code that works in case someone else needs it for this particular version. 
  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I just noticed something that might matter here, too.  Without getting into too much detail, I just discovered that there is already code inside the portal that seems to deal with this.  It should do the same thing as my code if the grid does not have a "WorkItemType" column.  Why it is still defaulting everything to a work item is a mystery now.  More importantly, perhaps this code will not even be necessary much longer.
  • Mikhail_ScherbakovMikhail_Scherbakov Customer IT Monkey ✭
  • James_JohnsonJames_Johnson Customer IT Monkey ✭

    Hi @Mikhail_Scherbakov

    I never did get this fully working. If you use an OData Table in v9 (and maybe others?) it will link you directly to the hardware asset. I currently have a sql table and a OData setup for a few of my queries that way I can have both the hardware link in OData and full export to excel from the sql. (OData export doesn't seem to have paging enabled so only grabs partial results when large numbers are in the table)


    If I have some time later this week I might be able to revisit it if the OData doesn't work for you.


    James

Sign In or Register to comment.