Andrii,
I got my hands on a Helsinki dev instance. I installed the plugins that bring in the Demand Workbench. And I apologize but I didn't know that the Demand Workbench really isn't a Service Portal page. I assumed that it was because of the angular script you presented. So, I started digging more into to see what I can learn about it.
It looks to me that this is a UI Page that is only accessible on the ServiceNow side of things where only ServiceNow employees can touch the actual code. Or it could be generated from a Processor. Knowing the ServiceNow Platform you can usually override parts such as UI pages, UI macros and UI scripts by creating the same type within your instance with the same name. Then when the system runs it will use your custom page/macro/script instead of the OOB.
On the instance I was using I couldn't find the UI Script holding the angular script (sn.bubbleChartVisualization). So, I couldn't create a UI Script with the same name because I didn't know the actual name of the UI Script. I ended up taking a different route. I created a UI page with the script taken from the $demand_workbench page (recovered via Inspect Element > Sources click on $demand_workbench.do?.... ). I named the UI page demand_workbench.
I gave it a try and looked like everything worked as normal as I tried all the features comparing to the OOB $demand_workbench page. Then I created a UI script with the script you posted to disable the bubble context menu. Brought that UI script into the UI page (<script></script>) and that seemed to work; meaning the bubble context menu was disabled.
Below is the screenshot of the custom demand workbench page:
Keep in mind I didn't do a thorough test of it. But I thought it might give you some ideas of what can be done. That whole process really took about 10min since all of the code was already done.
I hope this helps in some way.
Here's a screencast overview of what I did. (Excuse the recording. It's not the best)
Ah, then yes you can copy that code, modify it, give it a different naming convention, then either make a UI Script and bring it in as a js include through the theme.
You'll probably want to make it while under the Demand Workbench application scope.
The other way is to copy the code starting from "function" to the end of the function. Then create an Angular Provider and select type "directive". Give it a name that you will use as the element/attribute (whatever is set in the 'restrict' property). Use camel case if you plan to make it multi-word. From there you would bring it into your widget through the Angular Provider related list found at the bottom of the widget form (not the widget editor). Now you should be able to use the new directive within the widget.
For example I created a custom snRecordPicker directive by taking the OOB code and modifying it. The start of the file looked like this
angular.module('sn.common.controls').directive('snRecordPicker', function($timeout, $http, urlTools, filterExpressionParser, $sanitize, i18n)
I took the "function" part of the script and put that into the Angular Provider form:
In the screenshot above you can see I gave it my own custom name. I also modified the script.
Screenshots below show the widget where I add the angular provider to the widget and then the html markup using my new directive:
Those are essentially the steps on how to do it as far as going the Angular Provider route. Albeit, the directive I used was not from a scoped application like Demand Workbench. So again you might have to create yours within that scope. I'm not positive on that though.
I hope this helps.
Oh, if you go the UI Script route, you would change the name of the directive by altering the text after the words ".directive" in the code you posted.
ie. ......directive('myBubbleContextMenu'......
or what ever your naming convention would be.
