ContributionsMost RecentMost LikesSolutionsRe: Upcoming Changes to JavaScript in Quickbase@Evan Martinez also I should add that I totally get why these steps are being taken. Removing these types of "hacks" further legitimizes the platform, I like what I see in terms of direction at QB. That being said, I hope that the long term solutions you're talking about: 1. Include the ability to add enhanced and complex reactivity to forms. 2. Aren't too "long term" :)Re: Upcoming Changes to JavaScript in Quickbase@Evan Martinez Pipelines is a decent solution to the problem but this really takes away the main benefit of JS in QB which is being dynamically reactive to events that occur against the DOM. Pipelines doesn't solve the problem fully, like in the scenario where the user must taken an additional action when presented with data returned from an API call. Re: Upcoming Changes to JavaScript in Quickbase+1 on what @Jeff Jeff is describing. Our Quickbase apps utilize external APIs hosted and maintained by our organization for address standardization & data enrichment, would love some info on how we can continue to offer this functionality by using code pages.Re: Upcoming Changes to JavaScript in Quickbase@Evan Martinez I utilize the API to develop custom reports (in the form of mini Vue WebApps) to deliver functionality not available in Quickbase reports. Even though pieces of the app are open to everyone on the internet, these reports (pages) should not be. I was able to resolve this problem by swapping out user token authentication for temp token authentication using the new JSON API, as the temp token allows for the QB authentication credential to be passed along with the request. When a token cannot be generated (in the event of a not logged in user), the app knows to not make the data fetch call and display an error instead.Re: Upcoming Changes to JavaScript in QuickbaseIs there the ability to add permissions to Code Pages? When the EOTI role is present in my app, it appears as though they have permission to view all of my code pages.Re: The next generation of the Quickbase API@Harrison Hersch Thanks Harrison, I will do that! I look forward to seeing an article posted regarding how this should be handled. Thanks for your prompt responses too!Re: The next generation of the Quickbase API@Harrison Hersch this would be for an EOTI permissioned app. What I am trying to accomplish is category #2 above. Not cross-domain communication within QuickBase. That's what prompted my question in the first place because in my experience I would expect an API to be "open" (not restricted by CORS) but require token based authentication for private resources. If a QuickBase app has an EOTI user with permission to access a table, then that table isn't considered a "private resource" and the user token is not required. It is up to the dev to permission the EOTI user with the appropriate access. The source of the request (client-side or server side) shouldn't matter. If a web app is hosted, for example, on AWS S3 should this theoretically work with the new API? But not currently with the existing API?Re: The next generation of the Quickbase API@Harrison Hersch Are those client side apps hosted externally, or pages that are hosted as "QuickBase Pages"? Myself and colleagues at my organization have not been able to leverage the QuickBase API directly from a client-side application. Are there any examples that you could provide? Below is a sample of what I would expect to work from a client-side app, but the result is this: "Access to fetch at 'https://MY_QB_DOMAIN.quickbase.com/db/MY_APP_DB_ID' from origin 'chrome-search://local-ntp' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled." var myHeaders = new Headers(); myHeaders.append("Content-Type", "application/xml"); myHeaders.append("QUICKBASE-ACTION", "API_AddRecord"); var raw = "<qdbapi>\n <udata>MY_APPLICATION</udata>\n <apptoken>MY_APP_TOKEN_GOES_HERE</apptoken>\n <field fid=\"6\">nick</field>\n <field fid=\"7\">1234 MARKET ST</field>\n</qdbapi>"; var requestOptions = { method: 'POST', headers: myHeaders, body: raw, redirect: 'follow' }; fetch("https://MY_QB_DOMAIN.quickbase.com/db/MY_APP_DB_ID", requestOptions) .then(response => response.text()) .then(result => console.log(result)) .catch(error => console.log('error', error)); Re: The next generation of the Quickbase APIWill it be possible to create client-side apps that utilize the QuickBase API? ie: will the CORS restriction be lifted from this new API?RE: AMA on App Planning with Orientation Success Manager Lee Gilmore on September 26th from 2-3 PM ESTAre there any plans to officially support Continuous Integration for custom code pages via API_AddReplaceDBPage? An official, well documented and exampled CLI tool offered by QuickBase would be a huge advantage for properly planning and deploying more custom solutions that leverage QuickBase & the QuickBase API. ------------------------------ Nick Wade ------------------------------