Add schemas for Rules condition plugins

Same here, this raises two problems;

1) UI - as @dkre attached, totally those tabs confuse us. The wording "Negate the condition" is hard to understand. Maybe that means to revert from TRUE to FALSE or FALSE to TRUE, but why don't we use "Enable the condition" and should implement as it is since from a user perspective, s/he want to enable only the limited conditions if necessary.

2) Function - as @dkre mentioned, "Also by default a block is not visible if it is created or edited after rules is installed." This is more critical problem for me. If I edit an existing block and save it, Rule module doesn't look respect the checked "Negate the condition" options. I tried to export the config data from "Single Export" and it includes all the rules option entries in YAML config data with appropriate data such as "negate: 1", however it doesn't work.

I am using core 8.3.x and rules-8.x-3.x-dev.

Ran into this after updating to Drupal 8.2 this morning. Blocks that are supposed to appear on all pages are picking up a dependency on Rules, a whole collection of additional constraints, and not appearing at all after block save. I updates the site's config by hand to remove the dependency and remove the extra constraints and then re-imported the configuration and it resolved the issue (until the next time we want to change a block).

The page title block's config became:

uuid: 24e32cd5-4d1c-425d-a74c-0fdfe2293494
langcode: en
status: true
dependencies:
  module:
    - rules
  theme:
    - custom_theme
_core:
  default_config_hash: 7rR9chwXvdM2H8OYMAYx9Zj3GGlPMrZp_M3ZA4thYTk
id: custom_theme_page_title
theme: custom_theme
region: content
weight: -6
provider: null
plugin: page_title_block
settings:
  id: page_title_block
  label: 'Page title'
  provider: core
  label_display: '0'
visibility:
  rules_user_has_role:
    id: rules_user_has_role
    negate: 0
    context_mapping:
      user: '@user.current_user_context:current_user'
  rules_entity_has_field:
    id: rules_entity_has_field
    negate: 0
    context_mapping: {  }
  rules_node_is_promoted:
    id: rules_node_is_promoted
    negate: 0
    context_mapping:
      node: '@node.node_route_context:node'
  rules_data_is_empty:
    id: rules_data_is_empty
    negate: 0
    context_mapping:
      data: '@language.current_language_context:language_interface'
  rules_user_is_blocked:
    id: rules_user_is_blocked
    negate: 0
    context_mapping:
      user: '@user.current_user_context:current_user'
  rules_node_is_sticky:
    id: rules_node_is_sticky
    negate: 0
    context_mapping:
      node: '@node.node_route_context:node'
  rules_entity_is_of_type:
    id: rules_entity_is_of_type
    negate: 0
    context_mapping: {  }
  rules_list_contains:
    id: rules_list_contains
    negate: 0
    context_mapping:
      item: '@language.current_language_context:language_interface'
  rules_entity_is_new:
    id: rules_entity_is_new
    negate: 0
    context_mapping: {  }
  rules_list_count_is:
    id: rules_list_count_is
    negate: 0
    context_mapping: {  }
  rules_data_comparison:
    id: rules_data_comparison
    negate: 0
    context_mapping:
      data: '@language.current_language_context:language_interface'
      value: '@language.current_language_context:language_interface'
  rules_node_is_of_type:
    id: rules_node_is_of_type
    negate: 0
    context_mapping:
      node: '@node.node_route_context:node'
  rules_node_is_published:
    id: rules_node_is_published
    negate: 0
    context_mapping:
      node: '@node.node_route_context:node'
  rules_path_alias_exists:
    id: rules_path_alias_exists
    negate: 0
    context_mapping: {  }
  rules_entity_field_access:
    id: rules_entity_field_access
    negate: 0
    context_mapping:
      user: '@user.current_user_context:current_user'
  rules_path_has_alias:
    id: rules_path_has_alias
    negate: 0
    context_mapping: {  }
  rules_entity_is_of_bundle:
    id: rules_entity_is_of_bundle
    negate: 0
    context_mapping: {  }

Once I removed

dependencies:
  module:
    - rules

and all the visibility constraints that start:

visibility:
  rules_

I could reload the config and get the blocks.

This is because rules condition plugins do not provide any config schema.
#2811519: Blocks do not appear after being placed with the Rules module enabled (or other missing schemata for Condition plugins) should fix the problem generically.

Tim's already posted the cause and core's workaround. Rules should definitely provide this schema, however the condition_plugin data type should instead be condition.plugin (see the list of core data types). I wonder if we're able to use a placeholder here, or if we'd have to change the naming for that (i.e. rules.user_has_role instead of rules_user_has_role):

condition.plugin.rules_*:
  type: condition.plugin

See also #2633232: Missing fallback plugin configuration schemas

This bug is catastrophic and makes the D8 rules module unusable.

See:

https://www.drupal.org/project/rules/issues/3019965

This bug is catastrophic and makes the D8 rules module unusable.

Well then perhaps you can review #4 and #5 and provide feedback.

The original poster's issue was fixed by #2811519: Blocks do not appear after being placed with the Rules module enabled (or other missing schemata for Condition plugins), and the current issue remains open in order to add condition schemas to Rules. #4 and #5 differ on what that should be, so if you want to help you can investigate the correct schema to use here and provide a patch.

And how does this relate to #3019965: rules module - after install, any block re-config causes block to disappear, unrecoverably? If it's the same, why did you open a new issue?

Per #5 and #3259453: Rename all Rules events

I think it should be:

condition.plugin.rules.*:
  type: condition.plugin

Here is a patch with this new syntax.

Not sure if this is the right way. Please check given the linked issue and #5.

please disregard my patch. as stated here the renaming applies to events not conditions or plugins.