Rasa - I want same reply for every kind of conversation start - rasa-nlu

I have few intents.
But what I want is, at the start of conversation not matter what is being asked I want to always give welcome message.
I tried few things to achieve this but didn't work.
rule: rule-3
conversation_start: true
steps:
intent: product_price
action: utter_greet
For example in my story if at any other places for same intent I want different action.
But for same intent at the start of conversation I want greet message.
But then when I implement above technique it says contradicting rule and story.
Please note - user can start conversation literally by anything (and thus I can't have intent for each and everything) and I always want to greet with welcome message.
How do I do this?

I have resolved this using slots.
For every intent I have these story:
stories:
- story: -story-1
steps:
- slot_was_set:
- start_conv: false
- intent: greet
- action: action_greet
- story: -story-2
steps:
- slot_was_set:
- start_conv: false
- intent: goodbye
- action: action_greet
- story: -story-3
steps:
- slot_was_set:
- start_conv: false
- intent: product_price
- action: action_greet
Now every real story always starts with this:
story: onroad_price greet1
steps:
slot_was_set:
start_conv: true
intent: onroad_price
action: action_onroad_price_query
intent: assert_yes
action: action_onroad_price_answer
story: onroad_price greet2
steps:
slot_was_set:
start_conv: true
intent: onroad_price
action: action_onroad_price_query
intent: assert_no
action: utter_more_help

I think your are searching it too far.
Normally you just set your start intent in the interface that your client is talking to, so that on the moment your client connects it will see the welcome message.
After he can ask any question he wants and hit any intent needed.

Related

How can I make an optional email settings in my Jelastic manifest and return the value to the user?

Let's say I have a Jelastic manifest where, in the settings section, I ask the user for an email address (to setup some service). Because the user using Jelastic already is logged on Jelastic with an email, it might make sense to propose to the user that she uses that email. It saves her typing during the manifest setup. So, ideally, what I would like to do is this:
settings:
fields:
- name: email
caption: Email
type: string
default: ${user.email}
Then, in the manifest success text, I would like to display it, along with other credentials for the deployed services in the installed Jelastic environment:
success:
text: |
**Email**: ${settings.email}
The email is typically used as a username in a service deployed on the new Jelastic environment and in the success text it would be displayed near the corresponding password.
This above is all nice, but it doesn't work. Indeed, I cannot use the ${user.email} in the default field for the email settings.
Currently, the only viable way I've found to make it work is as follows:
settings:
fields:
- name: useJelasticEmailAsEmail
type: toggle
caption: Use Jelastic Email
value: true
hidden: false
showIf:
false:
name: email
caption: email
type: string
required: true
Then, I can use it to install a service like so:
onInstall:
- script: 'return { result: 0, email: ${settings.useJelasticEmailAsEmail} ? "${user.email}" : "${settings.email}" };'
- install:
jps: my-service-manifest.yml
settings:
username: ${response.email}
However, after installation of my-service-manifest.yml, I have no access to the actually used email anymore, therefore I cannot use the ${response.email} in my success text, except maybe if my-service-manifest.yml returned the email somehow (possibly with a return statement?).
The thing is, I may have many services to install like that, but only one requires the email. Additionally, it might be that for some reason that service requiring the email must be installed first. In such a case, with the above solution, I'd need to propagate the email through all services in order to get it out to the success text. The email would be consumed by the first service and somehow returned to the next. The next service does not need the email, but must propagate it, therefore it should take it as settings argument and return it to the next service, and so on. This is not very nice to have a manifest taking arguments it doesn't need, therefore that solution is probably not the right one.
I find that very complicated for a very simple problem. There must be something easier to do, right? Can someone give me a hint?
I'd need a solution for a manifest where I have many of such optional parameters. Currently, I have an issue with the email and also with secrets. In my use-cases, it makes sense that these secrets be provided by me directly in the settings or that they be automatically generated with e.g. ${fn.password(20)}. For some installations I need to set them myself, for some other installations I need to let them be automatically generated.
So, the working solution I have found goes as follows, assuming I have 2 optional parameters:
in the settings section of my jps manifest, I do
settings:
fields:
- name: useOptionalParam1
type: toggle
caption: Use optional param1
value: true
hidden: false
showIf:
false:
name: param1
caption: Param1
type: string
required: true
- name: useOptionalParam2
type: toggle
caption: Use optional param2
value: true
hidden: false
showIf:
false:
name: param2
caption: Param2
type: string
required: true
define values for those params in the globals section (for the email, this is not necessary, because it is defined as user.email):
globals:
OPTIONAL_PARAM1: ${fn.password(20)}
OPTIONAL_PARAM2: ${fn.password(20)}
define an action like this:
actions:
getOptionalParams:
- script: 'return { result: 0, param1: ${settings.useOptionalParam1} ? "${globals.OPTIONAL_PARAM1}" : "${settings.param1}", param2: ${settings.useOptionalParam2} ? "${globals.OPTIONAL_PARAM2}" : "${settings.param2}" };'
call the action wherever necessary; for example, before the success text:
# settings, globals, nodes sections
[...]
onInstall:
- myVariousInstalls
- getOptionalParams
success:
text: |
**PARAM1**: ${response.param1}
**PARAM2**: ${response.param2}
Note the last call to getOptionalParams at the very end of the onInstall section. It is there to provide the response object to the success section. Interestingly, that works fine. The getOptionalParams action can also be called anywhere in the myVariousInstalls action. It must be called before an operation, for example like this:
actions:
[...]
myVariousInstalls:
- getOptionalParams
- install:
jps: path/to/manifest
settings:
param1: ${response.param1}
In so doing, I solve my initial problem.

yaml workflow missing start tag

I'm trying to use Go client to programmatically manage workflows. I'm using yaml, this is my workflow:
name: order-process
tasks:
- id: collect-money
type: payment-service
- id: fetch-items
type: inventory-service
switch:
- case: totalPrice > 100
goto: ship-parcel-with-insurance
- default: ship-parcel
- id: ship-parcel-with-insurance
type: shipment-service-premium
end: true
- id: ship-parcel
type: shipment-service
And when I deploy this, I can't visualize it in camunda operate, the page is stuck on loading
and I have this error in console:
Error: unparsable content detected
line: 0
column: 0
nested error: missing start tag
we are sorry but Operate only supports BPMN XML deployments at the moment. The YAML support in Zeebe is only rudimentary and not intended for real-world use cases. It becomes really hard to model complex processes with yaml, which is easily possible with BPMN. We highly encourage you to switch to the Zeebe Modeler to create your workflow models.
If you want to discuss this further, we are happy to welcome you in one of our community channels.

Issue with creating a documentation when using re-usable enums

The issue with creating documentation when using re-usable enums
My yaml file looks like this
openapi: 3.0.2 components: schemas:
Countries:
type: string
enum:
- Unknown
- Afghanistan
- Albania
- Algeria
- American Samoa
- "\u00c5landIslands"
- NotOtherwiseSpecified
, when I compile it creates the java classes correctly, however, is not creating the documentation, just gives me:
Countries-
and nothing more is displayed for that particular scheme. For the other schemes enum options are displayed, etc.
Can you help me with this problem? Is this an issue of swagger or I am mistaken somewhere. The example in the swagger website and my code are following the same rules: https://swagger.io/docs/specification/data-models/enums/.
I also posted similar question here: https://community.smartbear.com/t5/SwaggerHub/Issue-with-creating-a-documentation-when-using-re-usable-enums/m-p/191938
P.S. I thought the problem is coming because of the special character, but it is not. I tried without that specific enum entry and also I have another similar way reusable enum that behaves the same way.
This is working fine for me. I am attaching an example for reference of how I am doing it.
Parameters in route.yaml
parameters:
- name: Country
in: query
required: true
schema:
$ref: "#/components/schemas/test"
Declaration in parameters.yaml
components:
schemas:
test:
type: string
enum:
- Unknown
- Afghanistan
- Albania
- Algeria
- "\u00c5landIslands"
Attaching the image from Swagger UI
Please add some more details for reference as above mentioned are working fine for me.

timeout Exception even when element is already clicked

I am trying to click one button Sign In but even after button is clicked I am getting timeout exception.
I have verified the code and verified that I am using right locator.
description: CAP Demo
Navigate to the GitHub website, find the React repo using the
search functionality and go to the repo's homepage
actors:
- actor: WEB
segments:
- segment: 1
actions:
- description: Navigate to the GitHub homepage
action: org.getopentest.selenium.NavigateTo
args:
url: http://192.168.200.98:8780/CAFPortal/#/login
- description: Enter Login id
action: org.getopentest.selenium.SendKeys
args:
locator: {xpath: "//*[#id='login']/app-root/app-caf-login/div/div/div[2]/form/div[1]/input"}
text: ksood
sendEnter: true
- description: Enter password
action: org.getopentest.selenium.SendKeys
args:
locator: {xpath: "//*[#id='login']/app-root/app-caf-login/div/div/div[2]/form/div[2]/input"}
text: Acs#2018
sendEnter: true
- description: Pause for 60 second
action: org.getopentest.selenium.ActionsPause
args:
durationMs: 60000
- description: Display a greeting dialog box in the browser
action: org.getopentest.selenium.ExecuteScript
args:
script:
var message = "Hello World!";
alert(message);
- description: Click on sign in
action: org.getopentest.selenium.Click
args:
locator: {xpath: "//*[#id='login']/app-root/app-caf-login/div/div/div[2]/form/div[3]/div/div/button"}
Just want the last testcase to pass
You don't need the sendEnter: true argument with any of the SendKeys actions. When you pass sendEnter: true , the action will "press" the enter key after sending the keys to the textbox element. So basically, in the test you showed, the first action will input the username and then press enter, thus trying to log in without a password, which will of course fail.
The other problem is that you are using the ActionsPause keyword incorrectly (more info here). If you want to introduce a delay in your test, you can use the $delay() API, but you very rarely need to do this with OpenTest, since synchronization is built-in, meaning all test actions that perform some work on a UI element know how to wait for that element to be available before doing the work.

How to always run some ansible roles after previous failures?

I have a set of playbooks that do look like
- name: Run test
hosts: tester
roles:
- { role: setup_repos }
- { role: setup_environment }
- { role: install_packages }
- { role: run_tests }
- { role: collect_logs }
The current problem is that all over the first 4 roles we have ignore_errors: true which is not a good practice as it makes very hard to read the output and to debug.
The only reason why ignore_errors was abused was because we wanted to be able to perform the collect_logs at the end, regardless the outcome.
How can we refactor this in order to remove the ignore_errors and have a more of a fail-fast strategy.
Please note that we have lots of playbooks calling collect_logs role, so "moving code inside playbook" is not really a way to reuse it.
On ansible 2.4 or newer one should replace role: block with tasks like role_include or role_import, which gives you the ability to use normal logic used by tasks. You could use handlers, ignore_errors, and so on.
I belive handlers and notify would help you achive what you want.
You wont need to change your roles behavior (although it might be a good idea).
You should notify at the end of each of your roles, the handler would only run once.
http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change
Also if you choose to start handleing errors you could use the --force-handlers to force handler execution even when the playbook failed.
http://docs.ansible.com/ansible/latest/playbooks_error_handling.html#handlers-and-failure

Resources