I've written a RESTlet that works in our Sandbox environment. However, when I move the code to production and change the status to 'Released' and the Debug Level to 'Error', my code disappears. Specifically, I have a user event that creates a button that executes a RESTlet. I can see the button when the status is 'Testing', but as soon as the status gets changed to 'Released' I can no longer see the button. I haven't found much information on this, and it seems like this could be permissions error, but our Admin is out and I can't change my own permissions - is there a workaround to this?
I've tried changing the logging level and status levels.
Have you set the Audience on the Script Deployment record? Once you Release the Script, it is only accessible to the Employees/Roles/Groups/etc specified in the Audience.
Related
The DialogFlow CX with Page Form Parameters was working well in the test simulator and recently, my chat bots are not responding after user inputs.
When i tried to troubleshoot the issue i realized that the $page.params.status='FINAL' or the $page.params.someparameter.status='UPDATED' events are not firing properly. Due to this the routes are getting failed.
Initially i thought the issue is in my Project. Then i tried the prebuilt agent (travel-baggage claim) in another project. Even that behaves the same without any response after the user inputs are collected.
I also reported this issue to the Developer Advocates in Twitter and updating here as well to get some response from the community.
I’ve tried to replicate your use case but I was able to successfully trigger the condition routes $page.params.status = "FINAL" and $page.params.parameter-name.status = "UPDATED" as expected and transition to the defined page from my end.
See the following for reference:
$page.params.status = "FINAL"
$page.params.parameter-name.status = "UPDATED"
To troubleshoot the issue, you may check if all the conditions defined in your condition route are fulfilled. Also, you may need to check if the condition rules applied is OR or AND. If AND, make sure that all conditions are fulfilled in order to transition to the defined page or flow.
As for the prebuilt agent Travel: baggage claim, I was also able to replicate the same behavior. However, I noticed that this is a different issue since the issue is caused by the webhook being unable to provide a response and not caused by triggering the condition route. I was able to verify this by adding a static response on the condition route and by checking the logs from the simulator. See screenshots below for more information.
Static response
Log snippet from simulator
I tried creating a new flow and migrated all the pages and it works well. I suspect the flow got corrupted when i programmatically tried to update via API.
I am developing custom application in Oracle Apps which will call an oracle form named form.fmx
I have put form.fmx in FORM_PATH variable of default.env
I have created section called vikram in formsweb.cfg
I am accessing as http://prod.txis.com:7406/forms/frmservlet?config=vikram&form=form
And getting this error
URL validation failed. The error could have been caused through the use of the browser's navigation buttons ( the browser Back button or refresh, for example). If the error persists, Please contact system administrator.
Try one of the following methods to resolve your issue :
Goto Internet Options >> Security Tab >> Trusted sites >> Sites >>
Add this website to the zone.
Issue select fnd_profile.value('APPS_MAINTENANCE_MODE') from dual;
to see whether returns the result NORMAL, If this is not the case you're in the maintenance mode, and use :
sqlplus mySchema/myPassword#$AD_TOP/patch/115/sql/adsetmmd.sql DISABLE
Click on Lock and Edit, and then
Navigate to Domain structure >> Services >> Data sources Where you should see both oacore_cluster1 and forms_cluster1 in
the EBSDataSource targets.
Assume forms_cluster1 is missing in the EBSdatasource target list, then click on the EBSDatasource and then go to the
Targets section. In this page, check the box for forms_cluster1.
Save and Activate the changes and see the following view in you weblogic screen :
Issue was with Forms server configuration.
With correct config, it is running fine
I have an extension with a background page and a sandbox page where most of the content scripts execute.
Whenever I need to do an Ajax call it has to run in the background environment as otherwise I get a CORS error. Recently as of last week I believe, the chrome.runtime is no longer available in the sandbox environment for some reason. I can't find any notes etc about it and trying to figure out a solution how to communicate with background page now.
I had this in the sandbox environment to initialize a connect port to pass messages from an Ajax request
var ajaxCall = chrome.runtime.connect({name: "ajaxCall"});
Is there any info out there that I'm missing on why this change occurred and what are some possible workarounds?
Here's the output for chrome. 1st is the background page and 2nd is the sandbox. They used to be identical in both.
I have a background workflow that ends with a Stop step. This step has an optional Status Message attribute that I populate with some details I need to be logged.
After the workflow has run I can find the workflow Status Reason (="Succeeded") and other details in the corresponding System Job record. I would also expect to find the stored info in the Message field, but it's not there. I've tried static and dynamic Status Messages, but no success with neither.
Does anybody know where that message is stored?
Basically the Message in Details section of System Job is a placeholder for some useful error message/logging tracker to log with the help of ITracingService.Trace by developer or by platform when something breaks/exception captured.
The status reason is not the good place for logging success scenario message, rather for canceled scenario to pop custom message to user & rolling back the transaction.
Not sure why you want to store there, but better use a custom field or even a note (annotation) can help you in better way. Avoid storing successful workflow execution logs anyway.
Check in system jobs:
Also, uncheck this value:
Then, you could try running the workflow sync. I prefer this than waiting for the async service.
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.