In perspective We can set a DOMID to any component, it would be awesome to have something like document.getElementByID("MyId").props.text = "Foo and Bar" instead of self.parent.getChild("FlexContainer").getChild("MyId").props.text = "Foo and Bar" this will allow not to depend on component messaging to accomplish the goal of decoupling and shorten the development time. it will not be too efficient ( https://forum.inductiveautomation.com/t/select-elements-components-from-id-instead-of-hierarchical/82851/2?u=subin_adhikari ) but it certainly decreases the dev time.

when a client runs a report if it takes to long there just going to click away from that screen/ view and try again this can and has lead to some problems for us where we notice stuff running slowly then look ands see we have 4 reports trying t generate for the last 4 hours but none of them ever finish because the user clicked off there view. now when on the project there is a cancel reports option but im hoping we can get the same option added to perspective so we can stop the report with scripting when ever they clicked off the view

It would be nice to have some sort of report that shows where all the tags are being used

I'm aware of the proxy architecture, however the proxy doesn't help where the Ignition container is deploy/running. A proxy will allow for this: [Due to restricts of this forum, I can only put at the most 2 URLs in a post, so in the following scenario replace the _ with a dot .] proxy_com/ignition1 |---> ignition1_abc_com (deployed on Kubernetes cluster1) proxy_com/ignition2 |---> ignition2_abc_com (deployed on Kubernetes cluster2) You can't deploy more than 1 instances of Ignition on a Kubernetes clusters because all of the code currently depends on having the root context path (/). My goal is to have a proxy be able to route traffic to 2 (or more) instances of Ignition deployed to the same cluster: proxy_com/ignition1 |---> ignition_abc_com/ignition1 (deployed on Kubernetes cluster1) proxy_com/ignition2 |---> ignition_abc_com/ignition2 (deployed on Kubernetes cluster1) It doesn't make sense that I would need to create a new Kubernetes cluster each time I wanted to deploy an instance of Ignition. If the Kubernetes cluster has enough resources (CPU & Memory) it should be able to run as many instances of Ignition as we want. The root issue is that Ignition's links and redirects in the JavaScript are hardcoded to use the base context path of '/' and if there was just a way to pass in a variable as part of the Docker Build, that would be enough but I think this change would need implemented in the code base of Ignition as well. I did notice that at least part of the application uses a web.xml to handle some internal routes, it would be nice to have the ability to pass in a context root to that. Allowing for more flexibility to implement the product in the way the customer wants or needs.

It would be very helpful to have a supported Kafka Connector to integrate Ignition with Kafka for Tag History / Alarms / Audit Events etc.

Right now there is auto scaling as an option on the Axes for the Time series chart but that ether does it for both low and high or nether it would be nice if we could have only the high value auto scale and the low be fixed or vice versa

I have worked on projects where the customer wants to see a drawing with statuses for all units in a facility, approximately 1000 units. The user would be able to use the mouse wheel or buttons to zoom/pan the screen to more easily determine which unit is having problems. Currently you can zoom in on the Ignition designer using the zoom slider at the bottom of the screen. Could we have some scripting methods for zooming in and out on a client window?

Add basic drawing tools to Perspective (lines, circles, squares, etc.). If feasible, it would be fantastic to be able to group as well.

An search option for tags is needed. It can be really hard to find the tags you want to trend, when you don't know the tag path in the tag browser in the power chart

Currently, you can only have 3 licenses for Maker's edition. Please add an option to purchase additional licenses. Personally, I would gladly pay 20 USD for each individual license to give my various personal projects an HMI to monitor them with.