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