Forum Discussion
JakeRattner1
Qrew Cadet
Have the engineers at Quickbase ever seen major problems from JS in forms? I'm concerned that QB is losing tons of functionality for mostly acedemic reasons, but I'm not a JS expert so I'm totally open to being educated. Either way, I've worked for a few QSPs and as a QB admin at several companies and all use JS in forms (as well as iFrames, although rarely). I'm sure you've heard this before, but its so useful to have this functionality.
I am very strongly suggesting that you do not move forward with bocking JS in forms completely. Please instead coud you consider blocking by default and let the administrator decide if they would like to enable JS. Please take the same approach with iFrames.
------------------------------
Jake R
------------------------------
I am very strongly suggesting that you do not move forward with bocking JS in forms completely. Please instead coud you consider blocking by default and let the administrator decide if they would like to enable JS. Please take the same approach with iFrames.
------------------------------
Jake R
------------------------------
hhersch
4 years agoQrew Captain
Hi Jake. I'll jump in here as the person driving our multi-year UI refresh journey. Our priority as a platform is time-to-value, not necessarily pixel perfect control.
We have done significant research on this in the past 12 months. Many of our partners and customers have been involved in this. Arbitrary code in a place it wasn't intended in any software system is considered a security vulnerability. As a software platform that serves thousands of enterprise customers with rigorous security controls, security and supportability has to take precedence. In the case of Quick Base, the intended place for JavaScript code has always been code pages.
Without getting too far into the weeds, there are numerous conflicts that arise with unsupported code on any page, since we cannot regression test for it. As we are significantly investing in our interface, this only increases the likelihood issues will appear which we have no way to support. Even if an administrator approves it, there is still a support and maintenance challenge and things can break without notice.
Long term, we absolutely understand the value in extending the platform and have a detailed strategy in place to allow for further customization and power. That won't all be in the way of JavaScript though. Adding native capabilities, such as those to our formula engine, are going to reduce the need for the unsupported and supported code, getting you to the ideal experience faster.
Finally, we have an extensibility strategy we are building towards which will allow safe and intended extension points. For example in our new dashboards, we are exploring allowing builders to insert a custom code page to be inserted and receive filter events so that a custom chart or report can feel native to the end user. And in our new forms, iFrames will absolutely be supported. We just need to carefully keep the plates spinning between short term, long term, usability, supportability and security.
Hope this helps.
------------------------------
Harrison Hersch
Director of Product Operations
------------------------------
We have done significant research on this in the past 12 months. Many of our partners and customers have been involved in this. Arbitrary code in a place it wasn't intended in any software system is considered a security vulnerability. As a software platform that serves thousands of enterprise customers with rigorous security controls, security and supportability has to take precedence. In the case of Quick Base, the intended place for JavaScript code has always been code pages.
Without getting too far into the weeds, there are numerous conflicts that arise with unsupported code on any page, since we cannot regression test for it. As we are significantly investing in our interface, this only increases the likelihood issues will appear which we have no way to support. Even if an administrator approves it, there is still a support and maintenance challenge and things can break without notice.
Long term, we absolutely understand the value in extending the platform and have a detailed strategy in place to allow for further customization and power. That won't all be in the way of JavaScript though. Adding native capabilities, such as those to our formula engine, are going to reduce the need for the unsupported and supported code, getting you to the ideal experience faster.
Finally, we have an extensibility strategy we are building towards which will allow safe and intended extension points. For example in our new dashboards, we are exploring allowing builders to insert a custom code page to be inserted and receive filter events so that a custom chart or report can feel native to the end user. And in our new forms, iFrames will absolutely be supported. We just need to carefully keep the plates spinning between short term, long term, usability, supportability and security.
Hope this helps.
------------------------------
Harrison Hersch
Director of Product Operations
------------------------------