Hey everyone, we just noticed that a small subset of the issue checker errors that had been shown were not actually being enforced as deploy-blocking.
Most people should not be affected in any way by this change, since all the issues in question were already flagged as errors in the issue checker.
This involved mostly cross-page issues that would be clearly indicated as errors, such as:
- Go To Page actions not properly passing the expected Thing when the target page had a thing set
- Go To Page actions used in native apps.
We are planning on fixing this long-standing bug, but this may mean that some apps will temporarily be blocked from deploying until they fix these issues.
Some guidelines for addressing these:
- “native app” pages are used in order to allow some barebones compatibility with an app wrapper called Cordova, which, in our current relatively old implementation, is not compatible with page navigation. We therefore disallow page navigation towards “native apps”.
- If you encounter this, the easiest is to evaluate whether you need the “native app” setting in this context, and potentially remove if you don’t use the cordova wrapper.
- If you are actually using this in a native app wrapper, then consider whether you are using a redirection as a means to refresh the page that can be replaced with a Refresh Page action.
- Finally, if this is used as a way to change the Page’s thing, and your native app page has a page thing, we won’t be able to support this feature at the moment. We advise to rely on a different group to hold information about a given thing instead of setting the page’s thing, since native apps probably don’t need to display a URL with the page’s thing.
- Navigating to a page that has a type without passing it anything is not intrinsically problematic, but we show an issue nonetheless since the page probably expects to receive a Thing in the url. This could become an issue checker “warning” - but has been flagged as an error for legacy reasons, until we come up with a cleaner framework for raising non-blocking warnings
- if you encounter this, the easiest is to assess whether or not you need to give the page a Type if the type isn’t set when you navigate to it
- If you do need the type but really don’t want to pass anything for this one navigation action, then pass an empty search for that thing (Do a search for X [where id = impossible_id]:first item)
If after all this you are blocked from deploying, a temporary workaround is to append
&issues_off=true to your editor url which will temporarily disable the issue checker and allow you to deploy.
However, do note that this is highly inadvisable: you may be creating issues in your app that will be very hard to debug and cause subtle problems in runmode, so this should only be used as a last resort.
If anything blocking comes up, be sure to let our customer support team know!