Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schema:#/definitions/condition is treated the same as schema:#/definitions/booleanExpression #5334

Open
2 of 8 tasks
tomlm opened this issue Feb 18, 2021 · 3 comments
Open
2 of 8 tasks
Labels
Area: Adaptive The issue is related to Adaptive dialogs

Comments

@tomlm
Copy link
Contributor

tomlm commented Feb 18, 2021

Describe the bug

schema:#/definitions/condition indicates that the default UX for the property should be the expression editor. NOTE: It should NOT HAVE an equals.

schema:#/definitions/booleanExpression indicates that the value could be a bool TRUE/FALSE or an expression which evaluates to that.

If you look in the schema you can see that IfCondition action the condition is different then disabled

       "condition": {
            "$ref": "schema:#/definitions/condition",
            "title": "Condition",
            "description": "Expression to evaluate.",
            "examples": [
                "user.age > 3"
            ]
        },
        "disabled": {
            "$ref": "schema:#/definitions/booleanExpression",
            "title": "Disabled",
            "description": "Optional condition which if true will disable this action.",
            "examples": [
                true,
                "=user.age > 3"
            ]
        },

I have written 3 bots with composer and NOT ONCE have I had a trigger or IfCondition which was "TRUE/FALSE". 100% of the time it was an expression such as user.age > 3

The current UI is saying that the default for an If condition is true

   // writing a if statement like this almost never ever is done, because it's meaningless.
   if (true)

The effect of this bug is that I have to click 3 times EVERYTIME I create a new trigger or IfCondition.

  1. once to drop show menu
  2. once to select expression
  3. once to click on the input box.
    By the end of a long day I am swearing at the monitor.

Version

Browser

  • Electron distribution
  • Chrome
  • Safari
  • Firefox
  • Edge

OS

  • macOS
  • Windows
  • Ubuntu

To Reproduce

Steps to reproduce the behavior:

  1. Add a trigger with condition user.age > 3
  2. Add a IfCondition with condition user.name == 'john'

Expected behavior

I expect the schema design to be respected.

  1. Conditions should not be labeled as T/F and not have drop down menu. It should just be the expression editor without the '='.
  2. Boolean properties should have T/F and the drop as it does today.
  3. If I select expression for any expression property the focus should be placed on the input box so I don't have to have the third click.

This should be all places that /definitions/condition is used in the .schema files:

  • IfCondition action (the condition property)
  • all triggers (the condition property)
  • all ** Input dialogs (the validations array)

Screenshots

image

image

Additional context

@tomlm tomlm changed the title schema:#/definitions/condition is treated the same as schema:#/definitions/booleanExpression and they shouldn't schema:#/definitions/condition is treated the same as schema:#/definitions/booleanExpression Feb 18, 2021
@cwhitten
Copy link
Member

@tomlm @GeoffCoxMSFT has some suggestions here for the SDK that will make this easier for Composer, and will follow-up

@boydc2014 boydc2014 assigned yeze322 and unassigned GeoffCoxMSFT Mar 10, 2021
@yeze322
Copy link
Contributor

yeze322 commented Mar 10, 2021

We have some findings

  1. condition fields are displayed as a dropdown with boolean because of sdk.schema declares it as oneOf field (generated by dialog:merge).
    image
    image

  2. booleanExpression is fine, it will be displayed as an abc string field in Composer
    (if edit sdk.schema manually)
    image
    image
    67.png)

So for this problem, if we want to change all *.condition fields' behavior in Composer, it's better to update it in dotnet sdk as a thorough fix.

@cwhitten @boydc2014 FYI

@cwhitten cwhitten transferred this issue from microsoft/BotFramework-Composer Mar 22, 2021
@cwhitten cwhitten added Area: Adaptive The issue is related to Adaptive dialogs P0 Must Fix. Release-blocker labels Mar 22, 2021
@cwhitten
Copy link
Member

Transferred to botbuildet-dotnet.

@tomlm we believe this should be fixed in schema. From our understanding of the problem and a way to address it is to have condition stop defining it's interface as a oneOf for expression or boolean. Because the schema says it can be a boolean, the form provides the related selectable options (TRUE/FALSE).

@tracyboehrer tracyboehrer removed the P0 Must Fix. Release-blocker label Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Adaptive The issue is related to Adaptive dialogs
Projects
None yet
Development

No branches or pull requests

6 participants